On Fri, May 21 2021 at 18:07, Len Brown wrote:
> On Fri, May 21, 2021 at 3:10 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
