All of lore.kernel.org
 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: 16+ 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 of check_wait_context() 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-23  2:57     ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.