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.
