linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Harry Yoo <harry.yoo@oracle.com>, akpm@linux-foundation.org
Cc: cl@gentwo.org, linux-mm@kvack.org, rientjes@google.com,
	surenb@google.com, hao.li@linux.dev, bigeasy@linutronix.de,
	clrkwllms@kernel.org, rostedt@goodmis.org, paulmck@kernel.org,
	urezki@gmail.com
Subject: Re: [PATCH] mm/slab: fix false lockdep warning in __kfree_rcu_sheaf()
Date: Wed, 21 Jan 2026 16:28:55 +0100	[thread overview]
Message-ID: <ac7352d8-dc30-4ca2-a2b5-3470ba33e5e1@suse.cz> (raw)
In-Reply-To: <20260121131639.165960-1-harry.yoo@oracle.com>

On 1/21/26 14:16, Harry Yoo wrote:
> kvfree_call_rcu() can be called while holding a raw_spinlock_t.
> Since __kfree_rcu_sheaf() may acquire a spinlock_t (which becomes a
> sleeping lock on PREEMPT_RT) and violate lock nesting rules,
> kvfree_call_rcu() bypasses the sheaves layer entirely on PREEMPT_RT.
> 
> However, lockdep still complains about acquiring spinlock_t while holding
> raw_spinlock_t, even on !PREEMPT_RT where spinlock_t is a spinning lock.
> This causes a false lockdep warning [1]:
> 
>  =============================
>  [ BUG: Invalid wait context ]
>  6.19.0-rc6-next-20260120 #21508 Not tainted
>  -----------------------------
>  migration/1/23 is trying to lock:
>  ffff8afd01054e98 (&barn->lock){..-.}-{3:3}, at: barn_get_empty_sheaf+0x1d/0xb0
>  other info that might help us debug this:
>  context-{5:5}
>  3 locks held by migration/1/23:
>   #0: ffff8afd01fd89a8 (&p->pi_lock){-.-.}-{2:2}, at: __balance_push_cpu_stop+0x3f/0x200
>   #1: ffffffff9f15c5c8 (rcu_read_lock){....}-{1:3}, at: cpuset_cpus_allowed_fallback+0x27/0x250
>   #2: ffff8afd1f470be0 ((local_lock_t *)&pcs->lock){+.+.}-{3:3}, at: __kfree_rcu_sheaf+0x52/0x3d0
>  stack backtrace:
>  CPU: 1 UID: 0 PID: 23 Comm: migration/1 Not tainted 6.19.0-rc6-next-20260120 #21508 PREEMPTLAZY
>  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
>  Stopper: __balance_push_cpu_stop+0x0/0x200 <- balance_push+0x118/0x170
>  Call Trace:
>   <TASK>
>   __dump_stack+0x22/0x30
>   dump_stack_lvl+0x60/0x80
>   dump_stack+0x19/0x24
>   __lock_acquire+0xd3a/0x28e0
>   ? __lock_acquire+0x5a9/0x28e0
>   ? __lock_acquire+0x5a9/0x28e0
>   ? barn_get_empty_sheaf+0x1d/0xb0
>   lock_acquire+0xc3/0x270
>   ? barn_get_empty_sheaf+0x1d/0xb0
>   ? __kfree_rcu_sheaf+0x52/0x3d0
>   _raw_spin_lock_irqsave+0x47/0x70
>   ? barn_get_empty_sheaf+0x1d/0xb0
>   barn_get_empty_sheaf+0x1d/0xb0
>   ? __kfree_rcu_sheaf+0x52/0x3d0
>   __kfree_rcu_sheaf+0x19f/0x3d0
>   kvfree_call_rcu+0xaf/0x390
>   set_cpus_allowed_force+0xc8/0xf0
>   [...]
>   </TASK>
> 
> This wasn't triggered until sheaves were enabled for all slab caches,
> since kfree_rcu() wasn't being called with a raw spinlock held for
> caches with sheaves (vma, maple node).
> 
> As suggested by Vlastimil Babka, fix this by using a lockdep map with
> LD_WAIT_CONFIG wait type to tell lockdep that acquiring spinlock_t is valid
> in this case, as those spinlocks won't be used on PREEMPT_RT.
> 
> Note that kfree_rcu_sheaf_map should be acquired using _try() variant,
> otherwise the acquisition of the lockdep map itself will trigger an invalid
> wait context warning.
> 
> Reported-by: Paul E. McKenney <paulmck@kernel.org>
> Closes: https://lore.kernel.org/linux-mm/c858b9af-2510-448b-9ab3-058f7b80dd42@paulmck-laptop [1]
> Fixes: ec66e0d59952 ("slab: add sheaf support for batching kfree_rcu() operations")
> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>

Thanks a lot! Will add to the sheaves-for-all series.



      reply	other threads:[~2026-01-21 15:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-21 13:16 Harry Yoo
2026-01-21 15:28 ` Vlastimil Babka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac7352d8-dc30-4ca2-a2b5-3470ba33e5e1@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=cl@gentwo.org \
    --cc=clrkwllms@kernel.org \
    --cc=hao.li@linux.dev \
    --cc=harry.yoo@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@kernel.org \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=surenb@google.com \
    --cc=urezki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox