mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xiongwei Song <sxwjean@me.com>
To: peterz@infradead.org, mingo@redhat.com, will@kernel.org,
	longman@redhat.com, boqun.feng@gmail.com
Cc: linux-kernel@vger.kernel.org, Xiongwei Song <sxwjean@gmail.com>
Subject: [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of check_wait_context()
Date: Sun, 11 Jul 2021 22:14:28 +0800	[thread overview]
Message-ID: <20210711141430.896595-1-sxwjean@me.com> (raw)

From: Xiongwei Song <sxwjean@gmail.com>

We now always get a "Invalid wait context" warning with
CONFIG_PROVE_RAW_LOCK_NESTING=y, see the full warning below:

	[    0.705900] =============================
	[    0.706002] [ BUG: Invalid wait context ]
	[    0.706180] 5.13.0+ #4 Not tainted
	[    0.706349] -----------------------------
	[    0.706486] swapper/1/0 is trying to lock:
	[    0.706658] ffff898c01045998 (&n->list_lock){..-.}-{3:3}, at: deactivate_slab+0x2f4/0x570
	[    0.706759] other info that might help us debug this:
	[    0.706759] context-{2:2}
	[    0.706759] no locks held by swapper/1/0.
	[    0.706759] stack backtrace:
	[    0.706759] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.13.0+ #4
	[    0.706759] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
	[    0.706759] Call Trace:
	[    0.706759]  <IRQ>
	[    0.706759]  dump_stack_lvl+0x45/0x59
	[    0.706759]  __lock_acquire.cold+0x2bc/0x2ed
	[    0.706759]  ? __lock_acquire+0x3a5/0x2330
	[    0.706759]  lock_acquire+0xbb/0x2b0
	[    0.706759]  ? deactivate_slab+0x2f4/0x570
	[    0.706759]  _raw_spin_lock_irqsave+0x36/0x50
	[    0.706759]  ? deactivate_slab+0x2f4/0x570
	[    0.706759]  deactivate_slab+0x2f4/0x570
	[    0.706759]  ? find_held_lock+0x2b/0x80
	[    0.706759]  ? lock_release+0xbd/0x2b0
	[    0.706759]  ? tick_irq_enter+0x28/0xe0
	[    0.706759]  flush_cpu_slab+0x2f/0x50
	[    0.706759]  flush_smp_call_function_queue+0x133/0x1d0
	[    0.706759]  __sysvec_call_function_single+0x3e/0x190
	[    0.706759]  sysvec_call_function_single+0x65/0x90
	[    0.706759]  </IRQ>
	[    0.706759]  asm_sysvec_call_function_single+0x12/0x20
	[    0.706759] RIP: 0010:default_idle+0xb/0x10
	[    0.706759] Code: 8b 04 25 40 6f 01 00 f0 80 60 02 df c3 0f ae f0 0f ae 38 0f ae f0 eb b9 0f 1f 80 00 00 00 00 eb 07 0f 00 2d ef f4 50 00 fb f4 <c3> c
	[    0.706759] RSP: 0018:ffff96c8c006bef8 EFLAGS: 00000202
	[    0.706759] RAX: ffffffff9c2f66d0 RBX: 0000000000000001 RCX: 0000000000000001
	[    0.706759] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9c2f697f
	[    0.706759] RBP: ffff898c01201700 R08: 0000000000000001 R09: 0000000000000001
	[    0.706759] R10: 0000000000000039 R11: 0000000000000000 R12: 0000000000000000
	[    0.706759] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
	[    0.706759]  ? mwait_idle+0x70/0x70
	[    0.706759]  ? default_idle_call+0x3f/0x1e0
	[    0.706759]  default_idle_call+0x66/0x1e0
	[    0.706759]  do_idle+0x1fb/0x270
	[    0.706759]  ? _raw_spin_unlock_irqrestore+0x28/0x40
	[    0.706759]  cpu_startup_entry+0x14/0x20
	[    0.706759]  secondary_startup_64_no_verify+0xc2/0xcb

In this case the wait type of spin_lock is 3 and the wait type of
raw_spin_lock is 2, meanwhile deactivate_slab call is in hardirq context,
, which is waiting for wait type <= 2, so check_wait_context() will print
this warning. However, spin_lock and raw_spin_lock should be same wait
type in !PREEMPT_RT environment.

Wait type details, with CONFIG_PROVE_RAW_LOCK_NESTING=y:
	LD_WAIT_SPIN   = 2,
	LD_WAIT_CONFIG = 3,
, with !CONFIG_PROVE_RAW_LOCK_NESTING:
	LD_WAIT_CONFIG = LD_WAIT_SPIN = 2,
.

As we know, the semantics of spin_lock will be only changed in PREEMPT_RT
environment, hence the wait type of spin_lock can be bigger than
raw_spin_lock's.

The fix makes CONFIG_PROVE_RAW_LOCK_NESTING under CONFIG_PREEMPT_RT=y and
the warning will be fixed.

Furthermore, this warning doesn't exsit in PREEMPT_RT environment. Because
the RT kernel has already replaced all the spin_lock_*() with
raw_spin_lock_*() for the list_lock of node. It means the current wait
type that is in hardirq context is equal to the wait type of raw_spin_lock
in this case.

Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
 lib/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8acc01d7d816..083608106436 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1271,7 +1271,7 @@ config PROVE_LOCKING
 
 config PROVE_RAW_LOCK_NESTING
 	bool "Enable raw_spinlock - spinlock nesting checks"
-	depends on PROVE_LOCKING
+	depends on PROVE_LOCKING && PREEMPT_RT
 	default n
 	help
 	 Enable the raw_spinlock vs. spinlock nesting checks which ensure
-- 
2.30.2


             reply	other threads:[~2021-07-11 14:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-11 14:14 Xiongwei Song [this message]
2021-07-11 14:14 ` [RFC PATCH v1 2/3] locking/lockdep: Unify the return values " Xiongwei Song
2021-07-11 15:19   ` Waiman Long
2021-07-12  7:48     ` Xiongwei Song
2021-07-23  2:57   ` [locking/lockdep] e0a77a7a5a: WARNING:bad_unlock_balance_detected kernel test robot
2021-07-11 14:14 ` [PATCH v1 3/3] locking/lockdep,doc: Correct the max number of lock classes Xiongwei Song
2021-07-11 15:22   ` Waiman Long
2021-07-12  7:49     ` Xiongwei Song
2021-07-11 16:43 ` [RFC PATCH v1 1/3] locking/lockdep: Fix false warning of check_wait_context() Waiman Long
2021-07-12  8:18   ` Xiongwei Song
2021-07-12  8:50     ` Boqun Feng
2021-07-12  9:21       ` Xiongwei Song
2021-07-12 13:04     ` Waiman Long
2021-07-12 15:03       ` Xiongwei Song
2021-07-13  2:29       ` Xiongwei Song

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=20210711141430.896595-1-sxwjean@me.com \
    --to=sxwjean@me.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sxwjean@gmail.com \
    --cc=will@kernel.org \
    /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

all inboxes | Powered by JetHome®