Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU

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

On Wed, Mar 20, 2024 at 06:55:36PM +0000, Matthew Wilcox wrote:
> On Wed, Mar 20, 2024 at 07:48:01PM +0100, Vlastimil Babka wrote:
> > On 3/20/24 19:32, Dan Carpenter wrote:
> > > On Tue, Mar 12, 2024 at 03:46:32PM +0100, Vlastimil Babka wrote:
> > >> But if we change it to effectively mean GFP_NOFAIL (for non-costly
> > >> allocations), there should be a manageable number of places to change to a
> > >> variant that allows failure.
> > > 
> > > What does that even mean if GFP_NOFAIL can fail for "costly" allocations?
> > > I thought GFP_NOFAIL couldn't fail at all...
> > 
> > Yeah, the suggestion was that GFP_KERNEL would act as GFP_NOFAIL but only
> > for non-costly allocations. Anything marked GFP_NOFAIL would still be fully
> > nofail.
> 
> GFP_NOFAIL should still fail for allocations larger than KMALLOC_MAX_SIZE.
> Or should we interpret that as "die now"?  Or "go into an unkillable
> sleep"?  If the caller really has taken the opportunity to remove their
> error handling path, returning NULL will lead to a crash and a lot of
> beard stroking trying to understand why a GFP_NOFAIL allocation has
> returned NULL.  May as well BUG_ON(size > KMALLOC_MAX_SIZE) and give
> the developer a clear indication of what they did wrong.

Why do we even need KMALLOC_MAX_SIZE...?

Given that kmalloc internally switches to the page allocator when
needed, I would think that that's something we can do away with.