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
next 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®