Re: [PATCH v2] memcg: skip cgroup_file_notify if spinning is not allowed

[Shakeel Butt <shakeel.butt@linux.dev>]

On Mon, Sep 22, 2025 at 04:04:43PM -0700, Andrew Morton wrote:
> On Mon, 22 Sep 2025 15:02:03 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote:
> 
> > Generally memcg charging is allowed from all the contexts including NMI
> > where even spinning on spinlock can cause locking issues. However one
> > call chain was missed during the addition of memcg charging from any
> > context support. That is try_charge_memcg() -> memcg_memory_event() ->
> > cgroup_file_notify().
> > 
> > The possible function call tree under cgroup_file_notify() can acquire
> > many different spin locks in spinning mode. Some of them are
> > cgroup_file_kn_lock, kernfs_notify_lock, pool_workqeue's lock. So, let's
> > just skip cgroup_file_notify() from memcg charging if the context does
> > not allow spinning.
> > 
> > Alternative approach was also explored where instead of skipping
> > cgroup_file_notify(), we defer the memcg event processing to irq_work
> > [1]. However it adds complexity and it was decided to keep things simple
> > until we need more memcg events with !allow_spinning requirement.
> > 
> > Link: https://lore.kernel.org/all/5qi2llyzf7gklncflo6gxoozljbm4h3tpnuv4u4ej4ztysvi6f@x44v7nz2wdzd/ [1]
> > Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
> > Acked-by: Michal Hocko <mhocko@suse.com>
> 
> Fixes a possible kernel deadlock, yes?
> 
> Is a cc:stable appropriate and can we identify a Fixes: target?
> 
> Thanks.
> 
> (Did it ever generate lockdep warnings?)

The report is here:
https://lore.kernel.org/all/20250905061919.439648-1-yepeilin@google.com/

I am not sure about the Fixes tag though or more like which one to put
in the Fixes as we recently started supporting memcg charging for NMI
context or allowing bpf programs to do memcg charged allocations in
recursive context (see the above report for this recursive call chain).
There is no single commit which can be blamed here.

Alexei, what do you suggest?