Messages in this thread | | | From | Len Brown <> | Date | Tue, 31 Aug 2021 18:16:48 -0400 | Subject | Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to protect dynamic user state |
| |
On Tue, Aug 31, 2021 at 6:15 PM Len Brown <lenb@kernel.org> wrote: > > On Mon, Aug 30, 2021 at 2:04 PM Dave Hansen <dave.hansen@intel.com> wrote: > > > > On 8/24/21 4:17 PM, Len Brown wrote: > > > Even if your AMX thread pool threads were to invoke this system call > > > as soon as possible... > > > What is to say that the thread pool is created only at a time when memory > > > is available? A thread could be created 24 hours into program execution > > > under OOM conditions and this system call will return ENOMEM, and your program > > > will in all likelihood throw up its arms and exit at the exact same place > > > it would exit for transparently allocated buffers. > > > > I tried this exact line of reasoning with Thomas: it doesn't matter > > where we run out of memory, we still need the same memory and we're > > screwed either way. > > > > However, Thomas expressed a clear preference for ABIs which return > > memory failures explicitly at syscalls versus implicit failures which > > can happen on random instructions. > > > > One might say that the odds of checking for and handling a NULL value > > (or ENOMEM) are the same as installing a signal handler. *But*, it's > > infinitely easier to unroll state and recover from a NULL than it is to > > handle it from within a signal handler. In other words, the explicit > > ones *encourage* better programming. > > I agree. > Indeed, I believe that there is universal agreement that a synchronous > return code > from a system call is a far superior programming model than decoding > the location of a failure in a system call. (no, the IP isn't random -- it is
decoding the location of the failure in a *signal hander*
> always the 1st instruction in that thread to touch a TMM register). > > > I'd prefer removing the demand-driven allocation at this point. > > Adding a pre-allocate system call that can gracefully fail > (even though it never will) is independent from removing > demand-driver allocation. I would leave this to application > developers. Honestly, the kernel shouldn't care. > > -- > Len Brown, Intel Open Source Technology Center
-- Len Brown, Intel Open Source Technology Center
| |