linux-kernel - Re: [PATCH] mm/memcg: reorder retry checks for clarity in try_charge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <gktuqmvopl7pgbcaw3rwiq77vb2zguae3jfdxmwfgtetf3twu4@gcb5bubhxq64>
Date: Thu, 18 Dec 2025 00:08:24 -0800
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Dipendra Khadka <kdipendra88@...il.com>
Cc: akpm@...ux-foundation.org, cgroups@...r.kernel.org, hannes@...xchg.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, mhocko@...nel.org, muchun.song@...ux.dev, 
	roman.gushchin@...ux.dev
Subject: Re: [PATCH] mm/memcg: reorder retry checks for clarity in
 try_charge_memcg

This feels like AI generated responses and giving me the impression that
you are not really understanding what you have written here.

On Thu, Dec 18, 2025 at 07:36:13AM +0000, Dipendra Khadka wrote:
> > Why hopeless?
> 
> Because in this specific path the allocating task is already the OOM
> victim (TIF_MEMDIE set). Any reclaim attempt performed by that task is
> unlikely to make progress for its own allocation, since the kernel has
> already decided that freeing this task’s memory is the resolution
> mechanism. Reclaim may free some pages globally, but the victim itself
> will still be exiting shortly, making retries for its own allocation
> non-actionable.

Beside its own allocation, these retries also keep the usage of the
container below its limit. Under extreme condition we allow allocations
above the limit. Here we are failing the charge request. Will we start
seeing more ENOMEM in the exit path? Do you have a call stack where such
retries are happening?

> 
> > Why optimize for this case?
> 
> I agree this is a narrow case, but it is also a delicate one.

How is it a delicate one and what exactly delicate mean here?

> The
> motivation is not performance in the general sense, but avoiding extra
> complexity and repeated reclaim attempts in a code path that is already
> operating under exceptional conditions. The early exit reduces retry
> churn for a task that is guaranteed to terminate, without affecting
> non-victim allocators.
> 
> > Since oom_reaper will reap the memory of the killed process, do we
> > really care about if killed process is delayed a bit due to reclaim?
> 
> Not strongly from a functional standpoint. The concern is more about
> control flow clarity and avoiding unnecessary reclaim loops while the
> task is already in a terminal state. I agree that this is not a
> correctness issue by itself, but rather an attempt to avoid redundant
> work in an already resolved situation.

How is it a resolved situation? The dying process is in reclaim due to
limit.

> 
> > How is this relevant here?
> 
> This was meant to explain why exiting early does not introduce new
> failure modes for the victim task.

More chances of ENOMEMs?

> Even if the victim still performs
> allocations briefly, the slowpath mechanisms 

What slowpath mechanisms?

> already allow limited
> forward progress. I agree this does not directly justify the reordering
> by itself.
> 
> > Same, how is this relevant to victim safety?
> 
> Same answer here — these mechanisms ensure that the victim does not
> regress functionally if retries are skipped,

How GFP_NOFAIL doing force charge is relevant to the case you are trying
to optimize?