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.
