From: Jiunn Chang <c0d1n61at3@gmail.com>
To: skhan@linuxfoundation.org
Cc: linux-kernel-mentees@lists.linuxfoundation.org,
rcu@vger.kernel.org, paulmck@linux.ibm.com,
josh@joshtriplett.org, rostedt@goodmis.org,
mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com,
joel@joelfernandes.org, corbet@lwn.net
Subject: [Linux-kernel-mentees][PATCH v3 3/6] Documentation: RCU: Convert RCU UP systems to reST
Date: Tue, 25 Jun 2019 01:26:24 -0500 [thread overview]
Message-ID: <20190625062627.26378-4-c0d1n61at3@gmail.com> (raw)
In-Reply-To: <20190623081413.7095-1-c0d1n61at3@gmail.com>
RCU UP systems reST markup.
Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
Documentation/RCU/UP.txt | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/Documentation/RCU/UP.txt b/Documentation/RCU/UP.txt
index 53bde717017b..67715a47ae89 100644
--- a/Documentation/RCU/UP.txt
+++ b/Documentation/RCU/UP.txt
@@ -1,17 +1,19 @@
-RCU on Uniprocessor Systems
+.. _up_doc:
+RCU on Uniprocessor Systems
+===========================
A common misconception is that, on UP systems, the call_rcu() primitive
may immediately invoke its function. The basis of this misconception
is that since there is only one CPU, it should not be necessary to
wait for anything else to get done, since there are no other CPUs for
-anything else to be happening on. Although this approach will -sort- -of-
+anything else to be happening on. Although this approach will *sort of*
work a surprising amount of the time, it is a very bad idea in general.
This document presents three examples that demonstrate exactly how bad
an idea this is.
-
Example 1: softirq Suicide
+--------------------------
Suppose that an RCU-based algorithm scans a linked list containing
elements A, B, and C in process context, and can delete elements from
@@ -28,8 +30,8 @@ your kernel.
This same problem can occur if call_rcu() is invoked from a hardware
interrupt handler.
-
Example 2: Function-Call Fatality
+---------------------------------
Of course, one could avert the suicide described in the preceding example
by having call_rcu() directly invoke its arguments only if it was called
@@ -46,11 +48,13 @@ its arguments would cause it to fail to make the fundamental guarantee
underlying RCU, namely that call_rcu() defers invoking its arguments until
all RCU read-side critical sections currently executing have completed.
-Quick Quiz #1: why is it -not- legal to invoke synchronize_rcu() in
- this case?
+Quick Quiz #1:
+ Why is it *not* legal to invoke synchronize_rcu() in this case?
+:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
Example 3: Death by Deadlock
+----------------------------
Suppose that call_rcu() is invoked while holding a lock, and that the
callback function must acquire this same lock. In this case, if
@@ -76,25 +80,30 @@ there are cases where this can be quite ugly:
If call_rcu() directly invokes the callback, painful locking restrictions
or API changes would be required.
-Quick Quiz #2: What locking restriction must RCU callbacks respect?
+Quick Quiz #2:
+ What locking restriction must RCU callbacks respect?
+:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
Summary
+-------
Permitting call_rcu() to immediately invoke its arguments breaks RCU,
even on a UP system. So do not do it! Even on a UP system, the RCU
-infrastructure -must- respect grace periods, and -must- invoke callbacks
+infrastructure *must* respect grace periods, and *must* invoke callbacks
from a known environment in which no locks are held.
-Note that it -is- safe for synchronize_rcu() to return immediately on
-UP systems, including !PREEMPT SMP builds running on UP systems.
+Note that it *is* safe for synchronize_rcu() to return immediately on
+UP systems, including PREEMPT SMP builds running on UP systems.
-Quick Quiz #3: Why can't synchronize_rcu() return immediately on
- UP systems running preemptable RCU?
+Quick Quiz #3:
+ Why can't synchronize_rcu() return immediately on UP systems running
+ preemptable RCU?
+.. _answer_quick_quiz_up:
Answer to Quick Quiz #1:
- Why is it -not- legal to invoke synchronize_rcu() in this case?
+ Why is it *not* legal to invoke synchronize_rcu() in this case?
Because the calling function is scanning an RCU-protected linked
list, and is therefore within an RCU read-side critical section.
@@ -119,7 +128,7 @@ Answer to Quick Quiz #2:
This restriction might seem gratuitous, since very few RCU
callbacks acquire locks directly. However, a great many RCU
- callbacks do acquire locks -indirectly-, for example, via
+ callbacks do acquire locks *indirectly*, for example, via
the kfree() primitive.
Answer to Quick Quiz #3:
--
2.22.0
WARNING: multiple messages have this Message-ID (diff)
From: c0d1n61at3 at gmail.com (Jiunn Chang)
Subject: [Linux-kernel-mentees] [PATCH v3 3/6] Documentation: RCU: Convert RCU UP systems to reST
Date: Tue, 25 Jun 2019 01:26:24 -0500 [thread overview]
Message-ID: <20190625062627.26378-4-c0d1n61at3@gmail.com> (raw)
In-Reply-To: <20190623081413.7095-1-c0d1n61at3@gmail.com>
RCU UP systems reST markup.
Signed-off-by: Jiunn Chang <c0d1n61at3 at gmail.com>
Reviewed-by: Joel Fernandes (Google) <joel at joelfernandes.org>
---
Documentation/RCU/UP.txt | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/Documentation/RCU/UP.txt b/Documentation/RCU/UP.txt
index 53bde717017b..67715a47ae89 100644
--- a/Documentation/RCU/UP.txt
+++ b/Documentation/RCU/UP.txt
@@ -1,17 +1,19 @@
-RCU on Uniprocessor Systems
+.. _up_doc:
+RCU on Uniprocessor Systems
+===========================
A common misconception is that, on UP systems, the call_rcu() primitive
may immediately invoke its function. The basis of this misconception
is that since there is only one CPU, it should not be necessary to
wait for anything else to get done, since there are no other CPUs for
-anything else to be happening on. Although this approach will -sort- -of-
+anything else to be happening on. Although this approach will *sort of*
work a surprising amount of the time, it is a very bad idea in general.
This document presents three examples that demonstrate exactly how bad
an idea this is.
-
Example 1: softirq Suicide
+--------------------------
Suppose that an RCU-based algorithm scans a linked list containing
elements A, B, and C in process context, and can delete elements from
@@ -28,8 +30,8 @@ your kernel.
This same problem can occur if call_rcu() is invoked from a hardware
interrupt handler.
-
Example 2: Function-Call Fatality
+---------------------------------
Of course, one could avert the suicide described in the preceding example
by having call_rcu() directly invoke its arguments only if it was called
@@ -46,11 +48,13 @@ its arguments would cause it to fail to make the fundamental guarantee
underlying RCU, namely that call_rcu() defers invoking its arguments until
all RCU read-side critical sections currently executing have completed.
-Quick Quiz #1: why is it -not- legal to invoke synchronize_rcu() in
- this case?
+Quick Quiz #1:
+ Why is it *not* legal to invoke synchronize_rcu() in this case?
+:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
Example 3: Death by Deadlock
+----------------------------
Suppose that call_rcu() is invoked while holding a lock, and that the
callback function must acquire this same lock. In this case, if
@@ -76,25 +80,30 @@ there are cases where this can be quite ugly:
If call_rcu() directly invokes the callback, painful locking restrictions
or API changes would be required.
-Quick Quiz #2: What locking restriction must RCU callbacks respect?
+Quick Quiz #2:
+ What locking restriction must RCU callbacks respect?
+:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
Summary
+-------
Permitting call_rcu() to immediately invoke its arguments breaks RCU,
even on a UP system. So do not do it! Even on a UP system, the RCU
-infrastructure -must- respect grace periods, and -must- invoke callbacks
+infrastructure *must* respect grace periods, and *must* invoke callbacks
from a known environment in which no locks are held.
-Note that it -is- safe for synchronize_rcu() to return immediately on
-UP systems, including !PREEMPT SMP builds running on UP systems.
+Note that it *is* safe for synchronize_rcu() to return immediately on
+UP systems, including PREEMPT SMP builds running on UP systems.
-Quick Quiz #3: Why can't synchronize_rcu() return immediately on
- UP systems running preemptable RCU?
+Quick Quiz #3:
+ Why can't synchronize_rcu() return immediately on UP systems running
+ preemptable RCU?
+.. _answer_quick_quiz_up:
Answer to Quick Quiz #1:
- Why is it -not- legal to invoke synchronize_rcu() in this case?
+ Why is it *not* legal to invoke synchronize_rcu() in this case?
Because the calling function is scanning an RCU-protected linked
list, and is therefore within an RCU read-side critical section.
@@ -119,7 +128,7 @@ Answer to Quick Quiz #2:
This restriction might seem gratuitous, since very few RCU
callbacks acquire locks directly. However, a great many RCU
- callbacks do acquire locks -indirectly-, for example, via
+ callbacks do acquire locks *indirectly*, for example, via
the kfree() primitive.
Answer to Quick Quiz #3:
--
2.22.0
WARNING: multiple messages have this Message-ID (diff)
From: c0d1n61at3@gmail.com (Jiunn Chang)
Subject: [Linux-kernel-mentees] [PATCH v3 3/6] Documentation: RCU: Convert RCU UP systems to reST
Date: Tue, 25 Jun 2019 01:26:24 -0500 [thread overview]
Message-ID: <20190625062627.26378-4-c0d1n61at3@gmail.com> (raw)
Message-ID: <20190625062624.aADRb1zr5EYJ-8b0AgWewVCERk_xklA6p6mAqKev9ag@z> (raw)
In-Reply-To: <20190623081413.7095-1-c0d1n61at3@gmail.com>
RCU UP systems reST markup.
Signed-off-by: Jiunn Chang <c0d1n61at3 at gmail.com>
Reviewed-by: Joel Fernandes (Google) <joel at joelfernandes.org>
---
Documentation/RCU/UP.txt | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/Documentation/RCU/UP.txt b/Documentation/RCU/UP.txt
index 53bde717017b..67715a47ae89 100644
--- a/Documentation/RCU/UP.txt
+++ b/Documentation/RCU/UP.txt
@@ -1,17 +1,19 @@
-RCU on Uniprocessor Systems
+.. _up_doc:
+RCU on Uniprocessor Systems
+===========================
A common misconception is that, on UP systems, the call_rcu() primitive
may immediately invoke its function. The basis of this misconception
is that since there is only one CPU, it should not be necessary to
wait for anything else to get done, since there are no other CPUs for
-anything else to be happening on. Although this approach will -sort- -of-
+anything else to be happening on. Although this approach will *sort of*
work a surprising amount of the time, it is a very bad idea in general.
This document presents three examples that demonstrate exactly how bad
an idea this is.
-
Example 1: softirq Suicide
+--------------------------
Suppose that an RCU-based algorithm scans a linked list containing
elements A, B, and C in process context, and can delete elements from
@@ -28,8 +30,8 @@ your kernel.
This same problem can occur if call_rcu() is invoked from a hardware
interrupt handler.
-
Example 2: Function-Call Fatality
+---------------------------------
Of course, one could avert the suicide described in the preceding example
by having call_rcu() directly invoke its arguments only if it was called
@@ -46,11 +48,13 @@ its arguments would cause it to fail to make the fundamental guarantee
underlying RCU, namely that call_rcu() defers invoking its arguments until
all RCU read-side critical sections currently executing have completed.
-Quick Quiz #1: why is it -not- legal to invoke synchronize_rcu() in
- this case?
+Quick Quiz #1:
+ Why is it *not* legal to invoke synchronize_rcu() in this case?
+:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
Example 3: Death by Deadlock
+----------------------------
Suppose that call_rcu() is invoked while holding a lock, and that the
callback function must acquire this same lock. In this case, if
@@ -76,25 +80,30 @@ there are cases where this can be quite ugly:
If call_rcu() directly invokes the callback, painful locking restrictions
or API changes would be required.
-Quick Quiz #2: What locking restriction must RCU callbacks respect?
+Quick Quiz #2:
+ What locking restriction must RCU callbacks respect?
+:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
Summary
+-------
Permitting call_rcu() to immediately invoke its arguments breaks RCU,
even on a UP system. So do not do it! Even on a UP system, the RCU
-infrastructure -must- respect grace periods, and -must- invoke callbacks
+infrastructure *must* respect grace periods, and *must* invoke callbacks
from a known environment in which no locks are held.
-Note that it -is- safe for synchronize_rcu() to return immediately on
-UP systems, including !PREEMPT SMP builds running on UP systems.
+Note that it *is* safe for synchronize_rcu() to return immediately on
+UP systems, including PREEMPT SMP builds running on UP systems.
-Quick Quiz #3: Why can't synchronize_rcu() return immediately on
- UP systems running preemptable RCU?
+Quick Quiz #3:
+ Why can't synchronize_rcu() return immediately on UP systems running
+ preemptable RCU?
+.. _answer_quick_quiz_up:
Answer to Quick Quiz #1:
- Why is it -not- legal to invoke synchronize_rcu() in this case?
+ Why is it *not* legal to invoke synchronize_rcu() in this case?
Because the calling function is scanning an RCU-protected linked
list, and is therefore within an RCU read-side critical section.
@@ -119,7 +128,7 @@ Answer to Quick Quiz #2:
This restriction might seem gratuitous, since very few RCU
callbacks acquire locks directly. However, a great many RCU
- callbacks do acquire locks -indirectly-, for example, via
+ callbacks do acquire locks *indirectly*, for example, via
the kfree() primitive.
Answer to Quick Quiz #3:
--
2.22.0
next prev parent reply other threads:[~2019-06-25 6:26 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-22 7:02 [Linux-kernel-mentees] [PATCH 2/3] Documentation: RCU: Convert RCU linked list to ReST c0d1n61at3
2019-06-22 7:02 ` Jiunn Chang
2019-06-22 15:00 ` corbet
2019-06-22 15:00 ` Jonathan Corbet
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 0/7] Documentation: RCU: Convert to c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
2019-06-23 23:39 ` joel
2019-06-23 23:39 ` Joel Fernandes
2019-06-24 0:39 ` corbet
2019-06-24 0:39 ` Jonathan Corbet
2019-06-25 6:26 ` [Linux-kernel-mentees][PATCH v3 0/6] Documentation: RCU: Convert to reST Jiunn Chang
2019-06-25 6:26 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-25 6:26 ` c0d1n61at3
2019-06-26 19:12 ` [Linux-kernel-mentees][PATCH v4 0/5] " Jiunn Chang
2019-06-26 19:12 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 19:12 ` c0d1n61at3
2019-06-26 20:07 ` [Linux-kernel-mentees][PATCH v5 " Jiunn Chang
2019-06-26 20:07 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 20:07 ` c0d1n61at3
2019-06-26 20:07 ` [Linux-kernel-mentees][PATCH v5 1/5] Documentation: RCU: Convert RCU basic concepts " Jiunn Chang
2019-06-26 20:07 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 20:07 ` c0d1n61at3
2019-06-27 14:34 ` [Linux-kernel-mentees][PATCH " Jonathan Corbet
2019-06-27 14:34 ` [Linux-kernel-mentees] [PATCH " Jonathan Corbet
2019-06-27 14:34 ` corbet
2019-06-27 15:13 ` [Linux-kernel-mentees][PATCH " Steven Rostedt
2019-06-27 15:13 ` [Linux-kernel-mentees] [PATCH " Steven Rostedt
2019-06-27 15:13 ` rostedt
2019-06-27 16:48 ` [Linux-kernel-mentees][PATCH " Shuah Khan
2019-06-27 16:48 ` [Linux-kernel-mentees] [PATCH " Shuah Khan
2019-06-27 16:48 ` skhan
2019-06-27 16:26 ` [Linux-kernel-mentees][PATCH " Paul E. McKenney
2019-06-27 16:26 ` [Linux-kernel-mentees] [PATCH " Paul E. McKenney
2019-06-27 16:26 ` paulmck
2019-06-27 16:47 ` [Linux-kernel-mentees][PATCH " Jiunn Chang
2019-06-27 16:47 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-27 16:47 ` c0d1n61at3
2019-06-26 20:07 ` [Linux-kernel-mentees][PATCH v5 2/5] Documentation: RCU: Convert RCU linked list " Jiunn Chang
2019-06-26 20:07 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 20:07 ` c0d1n61at3
2019-06-26 20:07 ` [Linux-kernel-mentees][PATCH v5 3/5] Documentation: RCU: Convert RCU UP systems " Jiunn Chang
2019-06-26 20:07 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 20:07 ` c0d1n61at3
2019-06-26 20:07 ` [Linux-kernel-mentees][PATCH v5 4/5] Documentation: RCU: Rename txt files to rst Jiunn Chang
2019-06-26 20:07 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 20:07 ` c0d1n61at3
2019-06-26 20:07 ` [Linux-kernel-mentees][PATCH v5 5/5] Documentation: RCU: Add TOC tree hooks Jiunn Chang
2019-06-26 20:07 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 20:07 ` c0d1n61at3
2019-06-26 19:12 ` [Linux-kernel-mentees][PATCH v4 1/5] Documentation: RCU: Convert RCU basic concepts to reST Jiunn Chang
2019-06-26 19:12 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 19:12 ` c0d1n61at3
2019-06-26 19:12 ` [Linux-kernel-mentees][PATCH v4 2/5] Documentation: RCU: Convert RCU linked list " Jiunn Chang
2019-06-26 19:12 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 19:12 ` c0d1n61at3
2019-06-26 19:12 ` [Linux-kernel-mentees][PATCH v4 3/5] Documentation: RCU: Convert RCU UP systems " Jiunn Chang
2019-06-26 19:12 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 19:12 ` c0d1n61at3
2019-06-26 19:12 ` [Linux-kernel-mentees][PATCH v4 4/5] Documentation: RCU: Rename txt files to rst Jiunn Chang
2019-06-26 19:12 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 19:12 ` c0d1n61at3
2019-06-26 19:12 ` [Linux-kernel-mentees][PATCH v4 5/5] Documentation: RCU: Add TOC tree hooks Jiunn Chang
2019-06-26 19:12 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-26 19:12 ` c0d1n61at3
2019-06-25 6:26 ` [Linux-kernel-mentees][PATCH v3 1/6] Documentation: RCU: Convert RCU basic concepts to reST Jiunn Chang
2019-06-25 6:26 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-25 6:26 ` c0d1n61at3
2019-06-25 6:26 ` [Linux-kernel-mentees][PATCH v3 2/6] Documentation: RCU: Convert RCU linked list " Jiunn Chang
2019-06-25 6:26 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-25 6:26 ` c0d1n61at3
2019-06-25 6:26 ` Jiunn Chang [this message]
2019-06-25 6:26 ` [Linux-kernel-mentees] [PATCH v3 3/6] Documentation: RCU: Convert RCU UP systems " Jiunn Chang
2019-06-25 6:26 ` c0d1n61at3
2019-06-25 16:03 ` [Linux-kernel-mentees][PATCH " Paul E. McKenney
2019-06-25 16:03 ` [Linux-kernel-mentees] [PATCH " Paul E. McKenney
2019-06-25 16:03 ` paulmck
2019-06-25 6:26 ` [Linux-kernel-mentees][PATCH v3 4/6] Documentation: RCU: Rename txt files to rst Jiunn Chang
2019-06-25 6:26 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-25 6:26 ` c0d1n61at3
2019-06-25 6:26 ` [Linux-kernel-mentees][PATCH v3 5/6] Documentation: RCU: Add links to rcu.rst Jiunn Chang
2019-06-25 6:26 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-25 6:26 ` c0d1n61at3
2019-06-25 15:56 ` [Linux-kernel-mentees][PATCH " Paul E. McKenney
2019-06-25 15:56 ` [Linux-kernel-mentees] [PATCH " Paul E. McKenney
2019-06-25 15:56 ` paulmck
2019-06-25 21:01 ` [Linux-kernel-mentees][PATCH " Jonathan Corbet
2019-06-25 21:01 ` [Linux-kernel-mentees] [PATCH " Jonathan Corbet
2019-06-25 21:01 ` corbet
2019-06-25 21:17 ` [Linux-kernel-mentees][PATCH " Paul E. McKenney
2019-06-25 21:17 ` [Linux-kernel-mentees] [PATCH " Paul E. McKenney
2019-06-25 21:17 ` paulmck
2019-06-25 21:40 ` [Linux-kernel-mentees][PATCH " Jonathan Corbet
2019-06-25 21:40 ` [Linux-kernel-mentees] [PATCH " Jonathan Corbet
2019-06-25 21:40 ` corbet
2019-06-25 21:45 ` [Linux-kernel-mentees][PATCH " Paul E. McKenney
2019-06-25 21:45 ` [Linux-kernel-mentees] [PATCH " Paul E. McKenney
2019-06-25 21:45 ` paulmck
2019-06-25 6:26 ` [Linux-kernel-mentees][PATCH v3 6/6] Documentation: RCU: Add TOC tree hooks Jiunn Chang
2019-06-25 6:26 ` [Linux-kernel-mentees] [PATCH " Jiunn Chang
2019-06-25 6:26 ` c0d1n61at3
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 1/7] Documentation: RCU: Convert RCU basic concepts to ReST c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
2019-06-23 23:34 ` joel
2019-06-23 23:34 ` Joel Fernandes
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 2/7] Documentation: RCU: Rename " c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 3/7] Documentation: RCU: Convert RCU linked list " c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
2019-06-23 23:31 ` joel
2019-06-23 23:31 ` Joel Fernandes
2019-06-24 0:43 ` corbet
2019-06-24 0:43 ` Jonathan Corbet
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 4/7] Documentation: RCU: Rename " c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 5/7] Documentation: RCU: Convert RCU UP systems " c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
2019-06-23 23:27 ` joel
2019-06-23 23:27 ` Joel Fernandes
2019-06-24 0:45 ` corbet
2019-06-24 0:45 ` Jonathan Corbet
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 6/7] Documentation: RCU: Rename " c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
2019-06-23 8:14 ` [Linux-kernel-mentees] [PATCH v2 7/7] Documentation: RCU: Add links to rcu.rst c0d1n61at3
2019-06-23 8:14 ` Jiunn Chang
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=20190625062627.26378-4-c0d1n61at3@gmail.com \
--to=c0d1n61at3@gmail.com \
--cc=corbet@lwn.net \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.ibm.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.