Skip to content

Commit a3b0a79

Browse files
mchehabpaulmckrcu
mchehab
authored and
paulmckrcu
committed
docs: RCU: Convert lockdep-splat.txt to ReST
- Add a SPDX header; - Add a document title; - Some whitespace fixes and new line breaks; - Mark literal blocks as such; - Add it to RCU/index.rst. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
1 parent 6b05dfa commit a3b0a79

File tree

2 files changed

+58
-52
lines changed

2 files changed

+58
-52
lines changed

‎Documentation/RCU/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,7 @@ RCU concepts
1111

1212
arrayRCU
1313
checklist
14+
lockdep-splat
1415
rcubarrier
1516
rcu_dereference
1617
whatisRCU

‎Documentation/RCU/lockdep-splat.txt renamed to ‎Documentation/RCU/lockdep-splat.rst

Lines changed: 57 additions & 52 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,9 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
=================
4+
Lockdep-RCU Splat
5+
=================
6+
17
Lockdep-RCU was added to the Linux kernel in early 2010
28
(http://lwn.net/Articles/371986/). This facility checks for some common
39
misuses of the RCU API, most notably using one of the rcu_dereference()
@@ -12,55 +18,54 @@ overwriting or worse. There can of course be false positives, this
1218
being the real world and all that.
1319

1420
So let's look at an example RCU lockdep splat from 3.0-rc5, one that
15-
has long since been fixed:
16-
17-
=============================
18-
WARNING: suspicious RCU usage
19-
-----------------------------
20-
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
21-
22-
other info that might help us debug this:
23-
24-
25-
rcu_scheduler_active = 1, debug_locks = 0
26-
3 locks held by scsi_scan_6/1552:
27-
#0: (&shost->scan_mutex){+.+.}, at: [<ffffffff8145efca>]
28-
scsi_scan_host_selected+0x5a/0x150
29-
#1: (&eq->sysfs_lock){+.+.}, at: [<ffffffff812a5032>]
30-
elevator_exit+0x22/0x60
31-
#2: (&(&q->__queue_lock)->rlock){-.-.}, at: [<ffffffff812b6233>]
32-
cfq_exit_queue+0x43/0x190
33-
34-
stack backtrace:
35-
Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
36-
Call Trace:
37-
[<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
38-
[<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
39-
[<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
40-
[<ffffffff812a5046>] elevator_exit+0x36/0x60
41-
[<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
42-
[<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
43-
[<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
44-
[<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
45-
[<ffffffff817da069>] ? error_exit+0x29/0xb0
46-
[<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
47-
[<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
48-
[<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
49-
[<ffffffff817da069>] ? error_exit+0x29/0xb0
50-
[<ffffffff812bcc60>] ? kobject_del+0x40/0x40
51-
[<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
52-
[<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
53-
[<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
54-
[<ffffffff8145f170>] do_scan_async+0x20/0x160
55-
[<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
56-
[<ffffffff810975b6>] kthread+0xa6/0xb0
57-
[<ffffffff817db154>] kernel_thread_helper+0x4/0x10
58-
[<ffffffff81066430>] ? finish_task_switch+0x80/0x110
59-
[<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
60-
[<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70
61-
[<ffffffff817db150>] ? gs_change+0xb/0xb
62-
63-
Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:
21+
has long since been fixed::
22+
23+
=============================
24+
WARNING: suspicious RCU usage
25+
-----------------------------
26+
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
27+
28+
other info that might help us debug this::
29+
30+
rcu_scheduler_active = 1, debug_locks = 0
31+
3 locks held by scsi_scan_6/1552:
32+
#0: (&shost->scan_mutex){+.+.}, at: [<ffffffff8145efca>]
33+
scsi_scan_host_selected+0x5a/0x150
34+
#1: (&eq->sysfs_lock){+.+.}, at: [<ffffffff812a5032>]
35+
elevator_exit+0x22/0x60
36+
#2: (&(&q->__queue_lock)->rlock){-.-.}, at: [<ffffffff812b6233>]
37+
cfq_exit_queue+0x43/0x190
38+
39+
stack backtrace:
40+
Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
41+
Call Trace:
42+
[<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
43+
[<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
44+
[<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
45+
[<ffffffff812a5046>] elevator_exit+0x36/0x60
46+
[<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
47+
[<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
48+
[<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
49+
[<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
50+
[<ffffffff817da069>] ? error_exit+0x29/0xb0
51+
[<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
52+
[<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
53+
[<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
54+
[<ffffffff817da069>] ? error_exit+0x29/0xb0
55+
[<ffffffff812bcc60>] ? kobject_del+0x40/0x40
56+
[<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
57+
[<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
58+
[<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
59+
[<ffffffff8145f170>] do_scan_async+0x20/0x160
60+
[<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
61+
[<ffffffff810975b6>] kthread+0xa6/0xb0
62+
[<ffffffff817db154>] kernel_thread_helper+0x4/0x10
63+
[<ffffffff81066430>] ? finish_task_switch+0x80/0x110
64+
[<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
65+
[<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70
66+
[<ffffffff817db150>] ? gs_change+0xb/0xb
67+
68+
Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows::
6469

6570
if (rcu_dereference(ioc->ioc_data) == cic) {
6671

@@ -70,7 +75,7 @@ case. Instead, we hold three locks, one of which might be RCU related.
7075
And maybe that lock really does protect this reference. If so, the fix
7176
is to inform RCU, perhaps by changing __cfq_exit_single_io_context() to
7277
take the struct request_queue "q" from cfq_exit_queue() as an argument,
73-
which would permit us to invoke rcu_dereference_protected as follows:
78+
which would permit us to invoke rcu_dereference_protected as follows::
7479

7580
if (rcu_dereference_protected(ioc->ioc_data,
7681
lockdep_is_held(&q->queue_lock)) == cic) {
@@ -85,7 +90,7 @@ On the other hand, perhaps we really do need an RCU read-side critical
8590
section. In this case, the critical section must span the use of the
8691
return value from rcu_dereference(), or at least until there is some
8792
reference count incremented or some such. One way to handle this is to
88-
add rcu_read_lock() and rcu_read_unlock() as follows:
93+
add rcu_read_lock() and rcu_read_unlock() as follows::
8994

9095
rcu_read_lock();
9196
if (rcu_dereference(ioc->ioc_data) == cic) {
@@ -102,7 +107,7 @@ above lockdep-RCU splat.
102107
But in this particular case, we don't actually dereference the pointer
103108
returned from rcu_dereference(). Instead, that pointer is just compared
104109
to the cic pointer, which means that the rcu_dereference() can be replaced
105-
by rcu_access_pointer() as follows:
110+
by rcu_access_pointer() as follows::
106111

107112
if (rcu_access_pointer(ioc->ioc_data) == cic) {
108113

0 commit comments

Comments
 (0)