diff options
| author | Johannes Thumshirn <[email protected]> | 2018-05-17 13:52:50 +0200 |
|---|---|---|
| committer | Keith Busch <[email protected]> | 2018-05-23 08:58:27 -0600 |
| commit | 978628ec795b18179e74ef12cfcd35bae569d13e (patch) | |
| tree | 3ed0f150c086817e072083703cdb6f23011d8ce2 /tools/perf/scripts/python/sched-migration.py | |
| parent | 327ea4adcfa37194739f1ec7c70568944d292281 (diff) | |
nvme: fix lockdep warning in nvme_mpath_clear_current_path
When running blktest's nvme/005 with a lockdep enabled kernel the test
case fails due to the following lockdep splat in dmesg:
=============================
WARNING: suspicious RCU usage
4.17.0-rc5 #881 Not tainted
-----------------------------
drivers/nvme/host/nvme.h:457 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by kworker/u32:5/1102:
#0: (ptrval) ((wq_completion)"nvme-wq"){+.+.}, at: process_one_work+0x152/0x5c0
#1: (ptrval) ((work_completion)(&ctrl->scan_work)){+.+.}, at: process_one_work+0x152/0x5c0
#2: (ptrval) (&subsys->lock#2){+.+.}, at: nvme_ns_remove+0x43/0x1c0 [nvme_core]
The only caller of nvme_mpath_clear_current_path() is nvme_ns_remove()
which holds the subsys lock so it's likely a false positive, but when
using rcu_access_pointer(), we're telling rcu and lockdep that we're
only after the pointer falue.
Fixes: 32acab3181c7 ("nvme: implement multipath access to nvme subsystems")
Signed-off-by: Johannes Thumshirn <[email protected]>
Suggested-by: Paul E. McKenney <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Keith Busch <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/sched-migration.py')
0 files changed, 0 insertions, 0 deletions