On Sat, Mar 02, 2024 at 08:33:34PM +0900, Tetsuo Handa wrote: > On 2024/03/02 9:02, Kent Overstreet wrote: > > Getting rid of those would be a really nice cleanup beacuse then gfp > > flags would mostly just be: > > - the type of memory to allocate (highmem, zeroed, etc.) > > - how hard to try (don't block at all, block some, block forever) > > I really wish that __GFP_KILLABLE is added, so that we can use like > mutex_trylock()/mutex_lock_killable()/mutex_lock(). > > Memory allocations from LSM modules for access control are willing to > give up when the allocating process is killed, for userspace won't know > about whether the request succeed. But such allocations are hardly > acceptable to give up unless the allocating process is killed or > allocation hit PAGE_ALLOC_COSTLY_ORDER, for ENOMEM failure returned by > e.g. open() can break the purpose of executing userspace processes > (i.e. as bad as being killed by the OOM killer). I'd be open to adding that, but does it really happen? For it to be useful, we'd have to have an allocation spending a significant amount of time in memory allocation such that the signal arrives while we're retrying. Do you have any details about times when you've seen this, eg sizes, other GFP flags, ... ?
