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

[Kent Overstreet <kent.overstreet@linux.dev>]

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.