On 6/16/26 15:47, Gregory Price wrote: > On Tue, Jun 16, 2026 at 11:57:42AM +0000, Brendan Jackman wrote: >> On Mon Jun 15, 2026 at 2:38 PM UTC, Vlastimil Babka (SUSE) wrote: >>> >>> I think the memalloc approach is dangerous due to unexpected nesting. There >>> might be nested page allocations in page allocation itself (due to some >>> debugging option). But also interrupts do not change what "current" points >>> to. Suddenly those could start requesting folios and/or private nodes and be >>> surprised, I'm afraid. >> >> Minor side-note: couldn't we just define it such that the allocator >> ignores the context when not in_task() (and warn if you try to enter the >> context while not currently in_task())? >> >> (Don't think this would change the conclusion very much, e.g. doesn't >> help with the nesting issues. Mostly curious in case I'm missing a >> detail here). >>
So I took a look at which nested allocations we could end up having, and I wonder whether gfp_nested_mask() indicates all these? If we could reliably identify them, all we'd have to do is safe+restore some context (activating a "nested" context). > > I looked at this - only solves one issue and oh boy is that an obtuse > confusing condition to understand. We still suffer from recursion in > reclaim. Right, we'd have to clear the context before calling into reclaim/compaction that does weird things. I'm sure BPF hooks could just arbitrarily try to allocate pages with kmalloc_nolock(). So that would require a context save/restore as well. -- Cheers, David
