Re: [PATCH 2/3] mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN

[Kent Overstreet <kent.overstreet@linux.dev>]

On Wed, Feb 07, 2024 at 08:24:33AM +0100, Vlastimil Babka wrote:
> On 2/6/24 22:50, Kent Overstreet wrote:
> > Introduce PF_MEMALLOC_* equivalents of some GFP_ flags:
> > 
> > PF_MEMALLOC_NORECLAIM	-> GFP_NOWAIT
> 
> In an ideal world, this would be nice, but we are in a world with implicit
> "too small to fail" guarantees that has so far been impossible to get away
> from [1] for small order GFP_KERNEL allocations, and this scoping would be
> only safe if no allocations underneath relied on this behavior. But how to
> ensure that's the case?

Fault injection. You can't know if code works if it never gets tested,
and if small allocations don't fail in practice, then you need fault
injection.

But there's a code pattern that absolutely requires GFP_NOWAIT. Say
you've got locks held and you want to allocate memory:

p = kmalloc(GFP_NOWAIT);
if (p)
	goto success;
unlock();
p = kmalloc(GFP_KERNEL);

/* unwind and retry, or tryrelock, depending on what you're doing */

that is - try the allocation nonblocking, then unlock or unwind, then
try it GFP_KERNEL.

bcachefs uses this heavily because we've got bch2_trans_unlock() and
bch2_trans_relock(); relock succeeds iff nothing else took write locks
on the nodes he had locked before - so we can safely use GFP_KERNEL
without causing deadlocks, only the occasional transaction restart.

but: the first GFP_NOWAIT allocation, before using GFP_KERNEL, is
absolutely required - calling unlock() has to be a slowpath operation,
otherwise it will livelock when multiple threads are contending for the
same locks.

More broadly, there's a bunch of other GFP_NOWAIT uses in the kernel,
and we're _not_ going to kill them off, and we are trying to kill off
gfp_t for this kind of purpose - so we need this.