docs: RCU: Convert lockdep-splat.txt to ReST (a3b0a79f) · Commits · 戴 / test

Documentation/RCU/index.rst

+1 −0

Original line number	Diff line number	Diff line
		@@ -11,6 +11,7 @@ RCU concepts

		arrayRCU
		checklist
		lockdep-splat
		rcubarrier
		rcu_dereference
		whatisRCU

Documentation/RCU/lockdep-splat.txt→Documentation/RCU/lockdep-splat.rst

+57 −52

Original line number	Diff line number	Diff line
		.. SPDX-License-Identifier: GPL-2.0

		=================
		Lockdep-RCU Splat
		=================

		Lockdep-RCU was added to the Linux kernel in early 2010
		(http://lwn.net/Articles/371986/). This facility checks for some common
		misuses of the RCU API, most notably using one of the rcu_dereference()
		@@ -12,15 +18,14 @@ overwriting or worse. There can of course be false positives, this
		being the real world and all that.

		So let's look at an example RCU lockdep splat from 3.0-rc5, one that
		has long since been fixed:
		has long since been fixed::

		=============================
		WARNING: suspicious RCU usage
		-----------------------------
		block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!

		other info that might help us debug this:

		other info that might help us debug this::

		rcu_scheduler_active = 1, debug_locks = 0
		3 locks held by scsi_scan_6/1552:
		@@ -60,7 +65,7 @@ Call Trace:
		[<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70
		[<ffffffff817db150>] ? gs_change+0xb/0xb

		Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:
		Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows::

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

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

		if (rcu_dereference_protected(ioc->ioc_data,
		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
		section. In this case, the critical section must span the use of the
		return value from rcu_dereference(), or at least until there is some
		reference count incremented or some such. One way to handle this is to
		add rcu_read_lock() and rcu_read_unlock() as follows:
		add rcu_read_lock() and rcu_read_unlock() as follows::

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

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

Admin message