On Wed, Mar 20, 2024 at 07:14:35PM +0000, Matthew Wilcox wrote: > 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. Ahh, my recollection was out of date - I believe that was 128k at one time?
