Commit 8f0cb666 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'core-rcu-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 

Pull RCU updates from Ingo Molnar:

 - kfree_rcu updates

 - RCU tasks updates

 - Read-side scalability tests

 - SRCU updates

 - Torture-test updates

 - Documentation updates

 - Miscellaneous fixes

* tag 'core-rcu-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (109 commits)
  torture: Remove obsolete "cd $KVM"
  torture: Avoid duplicate specification of qemu command
  torture: Dump ftrace at shutdown only if requested
  torture: Add kvm-tranform.sh script for qemu-cmd files
  torture: Add more tracing crib notes to kvm.sh
  torture: Improve diagnostic for KCSAN-incapable compilers
  torture: Correctly summarize build-only runs
  torture: Pass --kmake-arg to all make invocations
  rcutorture: Check for unwatched readers
  torture: Abstract out console-log error detection
  torture: Add a stop-run capability
  torture: Create qemu-cmd in --buildonly runs
  rcu/rcutorture: Replace 0 with false
  torture: Add --allcpus argument to the kvm.sh script
  torture: Remove whitespace from identify_qemu_vcpus output
  rcutorture: NULL rcu_torture_current earlier in cleanup code
  rcutorture: Handle non-statistic bang-string error messages
  torture: Set configfile variable to current scenario
  rcutorture: Add races with task-exit processing
  locktorture: Use true and false to assign to bool variables
  ...
parents 5ece0817 c1cc4784

Documentation/RCU/Design/Requirements/Requirements.rst

+6 −1
Original line number Original line Diff line number Diff line
@@ -2583,7 +2583,12 @@ not work to have these markers in the trampoline itself, because there 
would need to be instructions following ``rcu_read_unlock()``. Although

would need to be instructions following ``rcu_read_unlock()``. Although

``synchronize_rcu()`` would guarantee that execution reached the

``synchronize_rcu()`` would guarantee that execution reached the

``rcu_read_unlock()``, it would not be able to guarantee that execution

``rcu_read_unlock()``, it would not be able to guarantee that execution

had completely left the trampoline.

had completely left the trampoline. Worse yet, in some situations

the trampoline's protection must extend a few instructions *prior* to

execution reaching the trampoline.  For example, these few instructions

might calculate the address of the trampoline, so that entering the

trampoline would be pre-ordained a surprisingly long time before execution

actually reached the trampoline itself.





The solution, in the form of `Tasks

The solution, in the form of `Tasks

RCU <https://lwn.net/Articles/607117/>`__, is to have implicit read-side

RCU <https://lwn.net/Articles/607117/>`__, is to have implicit read-side

Documentation/RCU/checklist.txt→Documentation/RCU/checklist.rst

+12 −5
Original line number Original line Diff line number Diff line 
.. SPDX-License-Identifier: GPL-2.0



================================

Review Checklist for RCU Patches

Review Checklist for RCU Patches

================================









This document contains a checklist for producing and reviewing patches

This document contains a checklist for producing and reviewing patches
@@ -411,18 +415,21 @@ over a rather long period of time, but improvements are always welcome! 
	__rcu sparse checks to validate your RCU code.	These can help

	__rcu sparse checks to validate your RCU code.	These can help

	find problems as follows:

	find problems as follows:





	CONFIG_PROVE_LOCKING: check that accesses to RCU-protected data

	CONFIG_PROVE_LOCKING:

		check that accesses to RCU-protected data

		structures are carried out under the proper RCU

		structures are carried out under the proper RCU

		read-side critical section, while holding the right

		read-side critical section, while holding the right

		combination of locks, or whatever other conditions

		combination of locks, or whatever other conditions

		are appropriate.

		are appropriate.





	CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the

	CONFIG_DEBUG_OBJECTS_RCU_HEAD:

		check that you don't pass the

		same object to call_rcu() (or friends) before an RCU

		same object to call_rcu() (or friends) before an RCU

		grace period has elapsed since the last time that you

		grace period has elapsed since the last time that you

		passed that same object to call_rcu() (or friends).

		passed that same object to call_rcu() (or friends).





	__rcu sparse checks: tag the pointer to the RCU-protected data

	__rcu sparse checks:

		tag the pointer to the RCU-protected data

		structure with __rcu, and sparse will warn you if you

		structure with __rcu, and sparse will warn you if you

		access that pointer without the services of one of the

		access that pointer without the services of one of the

		variants of rcu_dereference().

		variants of rcu_dereference().
@@ -442,8 +449,8 @@ over a rather long period of time, but improvements are always welcome! 




	You instead need to use one of the barrier functions:

	You instead need to use one of the barrier functions:





	o	call_rcu() -> rcu_barrier()

	-	call_rcu() -> rcu_barrier()

	o	call_srcu() -> srcu_barrier()

	-	call_srcu() -> srcu_barrier()





	However, these barrier functions are absolutely -not- guaranteed

	However, these barrier functions are absolutely -not- guaranteed

	to wait for a grace period.  In fact, if there are no call_rcu()

	to wait for a grace period.  In fact, if there are no call_rcu()

Documentation/RCU/index.rst

+9 −0
Original line number Original line Diff line number Diff line 
.. SPDX-License-Identifier: GPL-2.0



.. _rcu_concepts:

.. _rcu_concepts:





============

============
@@ -8,10 +10,17 @@ RCU concepts 
   :maxdepth: 3

   :maxdepth: 3





   arrayRCU

   arrayRCU

   checklist

   lockdep

   lockdep-splat

   rcubarrier

   rcubarrier

   rcu_dereference

   rcu_dereference

   whatisRCU

   whatisRCU

   rcu

   rcu

   rculist_nulls

   rcuref

   torture

   stallwarn

   listRCU

   listRCU

   NMI-RCU

   NMI-RCU

   UP

   UP

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

+12 −7
Original line number Original line 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

Lockdep-RCU was added to the Linux kernel in early 2010

(http://lwn.net/Articles/371986/).  This facility checks for some common

(http://lwn.net/Articles/371986/).  This facility checks for some common

misuses of the RCU API, most notably using one of the rcu_dereference()

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.

being the real world and all that.





So let's look at an example RCU lockdep splat from 3.0-rc5, one 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

    WARNING: suspicious RCU usage

    -----------------------------

    -----------------------------

    block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() 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

    rcu_scheduler_active = 1, debug_locks = 0

    3 locks held by scsi_scan_6/1552:

    3 locks held by scsi_scan_6/1552:
@@ -60,7 +65,7 @@ Call Trace: 
    [<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70

    [<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70

    [<ffffffff817db150>] ? gs_change+0xb/0xb

    [<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) {

	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

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

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,

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,

	if (rcu_dereference_protected(ioc->ioc_data,

				      lockdep_is_held(&q->queue_lock)) == cic) {

				      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

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

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

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();

	rcu_read_lock();

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

	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

But in this particular case, we don't actually dereference the pointer

returned from rcu_dereference().  Instead, that pointer is just compared

returned from rcu_dereference().  Instead, that pointer is just compared

to the cic pointer, which means that the rcu_dereference() can be replaced

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) {

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

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

+8 −4
Original line number Original line Diff line number Diff line 
.. SPDX-License-Identifier: GPL-2.0



========================

RCU and lockdep checking

RCU and lockdep checking

========================





All flavors of RCU have lockdep checking available, so that lockdep is

All flavors of RCU have lockdep checking available, so that lockdep is

aware of when each task enters and leaves any flavor of RCU read-side

aware of when each task enters and leaves any flavor of RCU read-side
@@ -8,7 +12,7 @@ tracking to include RCU state, which can sometimes help when debugging 
deadlocks and the like.

deadlocks and the like.





In addition, RCU provides the following primitives that check lockdep's

In addition, RCU provides the following primitives that check lockdep's

state:

state::





	rcu_read_lock_held() for normal RCU.

	rcu_read_lock_held() for normal RCU.

	rcu_read_lock_bh_held() for RCU-bh.

	rcu_read_lock_bh_held() for RCU-bh.
@@ -63,7 +67,7 @@ checking of rcu_dereference() primitives: 
The rcu_dereference_check() check expression can be any boolean

The rcu_dereference_check() check expression can be any boolean

expression, but would normally include a lockdep expression.  However,

expression, but would normally include a lockdep expression.  However,

any boolean expression can be used.  For a moderately ornate example,

any boolean expression can be used.  For a moderately ornate example,

consider the following:

consider the following::





	file = rcu_dereference_check(fdt->fd[fd],

	file = rcu_dereference_check(fdt->fd[fd],

				     lockdep_is_held(&files->file_lock) ||

				     lockdep_is_held(&files->file_lock) ||
@@ -82,7 +86,7 @@ RCU read-side critical sections, in case (2) the ->file_lock prevents 
any change from taking place, and finally, in case (3) the current task

any change from taking place, and finally, in case (3) the current task

is the only task accessing the file_struct, again preventing any change

is the only task accessing the file_struct, again preventing any change

from taking place.  If the above statement was invoked only from updater

from taking place.  If the above statement was invoked only from updater

code, it could instead be written as follows:

code, it could instead be written as follows::





	file = rcu_dereference_protected(fdt->fd[fd],

	file = rcu_dereference_protected(fdt->fd[fd],

					 lockdep_is_held(&files->file_lock) ||

					 lockdep_is_held(&files->file_lock) ||
@@ -105,7 +109,7 @@ false and they are called from outside any RCU read-side critical section. 




For example, the workqueue for_each_pwq() macro is intended to be used

For example, the workqueue for_each_pwq() macro is intended to be used

either within an RCU read-side critical section or with wq->mutex held.

either within an RCU read-side critical section or with wq->mutex held.

It is thus implemented as follows:

It is thus implemented as follows::





	#define for_each_pwq(pwq, wq)

	#define for_each_pwq(pwq, wq)

		list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node,

		list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node,