Re: [PATCH RFC 1/4] mm/memcontrol: do not drain objcg stock when spinning is not allowed

[Harry Yoo <harry@kernel.org>]

On Fri, Jun 26, 2026 at 04:30:48PM +0200, Vlastimil Babka (SUSE) wrote:
> On 6/24/26 15:11, Harry Yoo (Oracle) wrote:
> > When kmalloc_nolock() drains objcg stock, the stock might be holding
> > the last reference to the objcg. Since obj_cgroup_release() is a
> > callback for percpu refcount and does not know whether spinning is
> > allowed, it is not safe to invoke obj_cgroup_put().
> > 
> > This was caught by lockdep on PREEMPT_RT because acquiring
> > a sleeping lock (objcg_lock) violates lock nesting rules:
> > 
> >   kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
> >   kernel: in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1267, name: systemd-resolve
> >   preempt_count: 1, expected: 0
> >   RCU nest depth: 3, expected: 3
> >   6 locks held by systemd-resolve/1267:
> >    #0: ffff888a8165fa20 ((&pcs->lock)){+.+.}-{3:3}, at: kmem_cache_alloc_noprof+0x185/0xa20
> >    #1: ffffffff9658a4c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x74/0x2a0
> >    #2: ffff888a81648598 ((lock)#4){+.+.}-{3:3}, at: trylock_stock+0x118/0x380
> >    #3: ffffffff9658a4c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x74/0x2a0
> >    #4: ffffffff9658a4c0 (rcu_read_lock){....}-{1:3}, at: percpu_ref_put_many.constprop.0+0x40/0x270
> >    #5: ffffffff96af11d8 (objcg_lock){+.+.}-{3:3}, at: obj_cgroup_release+0x8a/0x410
> >   [...]
> >   Call Trace:
> >    <TASK>
> >    dump_stack_lvl+0x8a/0xe0
> >    dump_stack+0x14/0x1c
> >    __might_resched.cold+0x233/0x2bb
> >    rt_spin_lock+0xd3/0x410
> >    obj_cgroup_release+0x8a/0x410
> >    percpu_ref_put_many.constprop.0+0x226/0x270
> >    drain_obj_stock_slot+0x27e/0x8d0
> >    __refill_obj_stock+0x409/0x6d0
> >    __memcg_slab_post_alloc_hook+0xa45/0x1500
> >    __kmalloc_nolock_noprof+0x988/0xc40
> >    [...]
> > 
> > However, this is illegal in !RT kernels too because the objcg release
> > callback acquires a spinlock even when spinning is not allowed.
> > 
> > To fix this issue, fall back to atomics when the cached objcg doesn't
> > match, but it is unsafe to drain because spinning is not allowed.
> > 
> > This is expected to affect performance of kmalloc_nolock() since
> > it can no longer drain and refill the stock and falls back to a
> > per-objcg atomic counter (objcg->nr_charged_bytes).
> 
> Maybe it's not bad that the constrained operation will not do a drain? Could
> we say it's likely that both _nolock() and normal operations will likely be
> happening on the same cpu for the same memcg, so a normal one will soon
> handle it?

I ended up making obj_cgroup_put() and obj_cgroup_release()
safe to call from any context as in RFC it's easy to overlook that
obj_cgroup_put() is not allowed if !allow_spin.

-- 
Cheers,
Harry / Hyeonggon