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

Vlastimil Babka
2024-03-20T18:48:03Z

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.

> 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/.

Maybe we could start producing warnings for costly GFP_KERNEL allocations to
get them converted away faster. Anything that's user-controlled most likely
shouldn't be GFP_KERNEL.

> From a static analysis perspective it would be nice if the callers
> explicitly marked which allocations can fail and which can't.

As I suggested, it would be nice not to wait until everything is explicitly
marked one way or another. I get the comparison with BKL, but also the
kernel got much larger since the BKL times?

Good point that it's not ideal if the size is unknown. Maybe the tools could
be used to point out places where the size cannot be determined, so those
should be converted first?

Also tools cound warn about attempts to handle failure to point out places
where it should be removed?

> regards,
> dan carpenter
>