Re: [PATCH v2] mm: memcontrol: raise MEMCG_MAX for charges that fail without reclaiming

[Shakeel Butt]

On Mon, Aug 31, 2026 at 10:48:35AM -0700, Joe Damato wrote:
> Charges that exceed memory.max and return through the nomem label can
> raise no event and simply return -ENOMEM.
> 
> A non-blocking charge can hit the limit, get rejected, but is not
> visible in memory.events.
> 
> This was noticed in a production setting where bpf_mem_alloc() attempted
> to refill its per-cpu freelists, which triggered a non-blocking charge
> while at the limit.
> 
> Commit d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for
> enforced allocations") added raised_max_event to cover charges that are
> force charged without ever reaching reclaim, but charges that are
> rejected outright were left out. Getting an allocation failure without
> the corresponding MEMCG_MAX event is unexpected and makes debugging and
> monitoring harder.
> 
> Raise the event on the way out for rejected charges as well, by routing
> the -ENOMEM return through the same exit path that already covers forced
> charges. The existing behavior of raising a MEMCG_MAX event on every
> charge/reclaim/retry iteration is left unchanged.
> 
> Tested with a module that performs accounted GFP_NOWAIT page allocations
> from a task in a cgroup at its memory.max, and measures the resulting
> memory.events:max delta. Without this patch the rejected charges raise
> no event at all; with it the delta matches the number of rejected charges
> exactly. A GFP_KERNEL|__GFP_NORETRY control, which reaches reclaim, raises
> the same two events per failed charge before and after, confirming the
> existing charge/reclaim/retry accounting is unchanged.
> 
> Fixes: d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations")
> Cc: stable@xxxxxxxxxxxxxxx
> Suggested-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>
> Signed-off-by: Joe Damato <joe@xxxxxxx>

Acked-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>