# Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

- From: Thomas Gleixner \<hidden\>
- Date: 2021-05-21 22:46:46 
- List: linux-api
- Page: https://ratatoskr.run/linux-api/2021/05/1388166
- Thread: https://ratatoskr.run/linux-api/2021/05/1387720/t.md

```text
On Fri, May 21 2021 at 18:07, Len Brown wrote:
> On Fri, May 21, 2021 at 3:10 PM Thomas Gleixner [ref] wrote:
> Regarding pre-allocation vs on-demand allocation, consider two scenarios:
>
> 1. Synchronous.  At process or thread start up time, prctl()
> synchronously allocates 8K context switch buffers.  Return code is 0
> -- good go go!  10 seconds later the program decides to create
> additional threads.  Woops. vmalloc failed, and the process
> synchronously dies.  bug filed.

No. pthread_create() will fail with -ENOMEM. A return value of
-ENOMEM is not a bug. 

If the application fails to check the error code then it's not the
kernels problem and not a kernel bug either.

> 2. On demand.  Same scenario, except vmalloc failure upon creation of
> those additional threads sends a SIGSEGV at the instruction where AMX
> is touched.  bug filed.
>
> Why ignore the 2nd bug and not ignore the 1st bug?

See above.

> My concern about synchronous allocation is that it will be very easy
> to abuse.  programs and threads can ask for buffers they will never
> use.  With on-demand allocation, we allocate buffers only if they are
> actually needed.

Programs ask for memory in various ways. The buffer is not any different
than any other memory allocation of the application/thread. It's
accounted for and when the limits are reached the allocation fails.

But it fails in a way which can be acted upon at the application level
and not in a way where the kernel has no other choice than killing the
whole process.

So where is the problem? 

Thanks,

        tglx
```