On 6/16/26 15:47, Gregory Price wrote:

On Tue, Jun 16, 2026 at 11:57:42AM +0000, Brendan Jackman wrote:

quoted

On Mon Jun 15, 2026 at 2:38 PM UTC, Vlastimil Babka (SUSE) wrote:

quoted

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