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

[Matthew Wilcox <willy@infradead.org>]

On Wed, Mar 20, 2024 at 03:07:38PM -0400, Kent Overstreet wrote:
> On Wed, Mar 20, 2024 at 06:55:36PM +0000, Matthew Wilcox wrote:
> > 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.

... maybe check what I said before replying?

/*
 * SLUB directly allocates requests fitting in to an order-1 page
 * (PAGE_SIZE*2).  Larger requests are passed to the page allocator.
 */
#define KMALLOC_SHIFT_MAX       (MAX_PAGE_ORDER + PAGE_SHIFT)

You caan't allocate larger than that without going to CMA or some other
custom allocator.

So.  The caller has requested NOFAIL, and requested a size larger than
we can allocate.  Do we panic, go into an uninterruptible sleep, or
return NULL?