On Wed, Mar 20, 2024 at 09:32:52PM +0300, 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... > > Unfortunately, it's common that when we can't decide on a sane limit for > something people just say "let the user decide based on how much memory > they have". I have added some integer overflow checks which allow the > user to allocate up to UINT_MAX bytes so I know this code is out > there. We can't just s/GFP_KERNEL/GFP_NOFAIL/. > > From a static analysis perspective it would be nice if the callers > explicitly marked which allocations can fail and which can't. GFP_NOFAIL throws a warning if the allocation size is > 2 pages, which is a separate issue from whether the allocation becomes fallible - someone would have to - oh, I don't know, read the code to answer that question. I think we can ditch the 2 page limit on GFP_NOFAIL, though.
