Re: [PATCH for-next-fixes v2 1/5] mm/memcontrol: defer obj_cgroup_release() to irq_work

[Harry Yoo]

On Wed, Nov 04, 2026 at 12:02:55PM +0100, Vlastimil Babka (SUSE) wrote:
> On 11/3/26 15:47, Harry Yoo (Meta) wrote:
> > obj_cgroup_put() can be called from any context.
> > __memcg_slab_free_hook() puts a per-object reference on
> > every accounted free, and draining a per-cpu objcg stock slot puts
> > the cached reference. When it drops the last reference,
> > obj_cgroup_release() takes objcg_lock, frees percpu memory
> > (pcpu_lock, via percpu_ref_exit()) and calls kfree_rcu(). Each of
> > these can deadlock when the current context interrupted a holder of
> > the respective lock.
> > 
> > Defer the release to irq_work. llist_add() and irq_work_queue() are
> > NMI-safe, and the irq_work runs in a context where acquiring a
> > spinlock is allowed.
> > 
> > Add a separate llist_node instead of reusing the list/rcu union
> > because the list stays linked until the deferred release. struct
> > obj_cgroup grows from 56 to 64 bytes, but both are served from
> > kmalloc-64, so no memory is additionally consumed.
> > 
> > Closes: https://lore.kernel.org/20261001044056.75079-3-kmehltretter@xxxxxxxxx
> > Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")
> > Signed-off-by: Harry Yoo (Meta) <harry@xxxxxxxxxx>
> 
> I guess releasing objcg isn't too frequent, so it won't matter that we make
> all cases use the defered work

Yeah, objcg release itself uses a global spinlock (objcg_lock),
so I think this is fine.

> instead of somehow trying to do that only in
> contexts that would really need it.

... and this is not easy as the percpu refcount callback
doesn't know the current context.

> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>

Thanks!

> since memcg tree will be used from the next cycle, we can just keep this as
> part of the series in the slab tree?

Ah, I see. Will do.

-- 
Cheers,
Harry / Hyeonggon