typo at Chp 7.

PATCH Applied Yubin Ruan 3 participants 19 messages Oct 27, 2017 – Oct 29, 2017

lore

Share & tools

lore

Yubin Ruan

author

2017-10-27 09:23 UTC #0 lore raw

PATCH 1/1 typo at Chp 7.

Hi paul,

I finish chapter 7 and find some typo. Fixed in the patch below.

Yubin

locking/locking-existence.tex +1 -1

index 9fcbbf9..c7c4ae8 100644
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,

Yubin Ruan

author

2017-10-27 02:25 UTC #1 lore raw

And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.

Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.

Thanks,
Yubin

locking/locking.tex +3 -3

index 14db27d..a9f46f1 100644
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
 \end{enumerate}
 
 These rules can be enforced by using tools similar to

@@ -2329,7 +2329,7 @@ locking's villainy.
 If there are a very large number of uses of a callback-heavy library,
 it may be wise to again add a parallel-friendly API to the library in
 order to allow existing users to convert their code incrementally.
-Alternatively, some advocate use of transactional memory in these cases.
+Alternatively, some advocate using transactional memory in these cases.
 While the jury is still out on transactional memory,
 Section~\ref{sec:future:Transactional Memory} discusses its strengths and
 weaknesses.

Akira Yokosawa

2017-10-27 15:18 UTC #2 lore raw

Quoted 15 lines · Yubin Ruan

And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644

locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170

Quoted 7 lines

locking/locking.tex +2 -2

@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.

The talking point here is library function and signal handler. So something like:

+ handler, then that signal must be blocked every time that one
+ of related library functions is called outside of the signal handler.

Thoughts?

Thanks, Akira

locking/locking.tex locking's villainy. · line 2332

Quoted 9 lines

locking/locking.tex +1 -1

 \end{enumerate}
 
 These rules can be enforced by using tools similar to

@@ -2329,7 +2329,7 @@ locking's villainy.
 If there are a very large number of uses of a callback-heavy library,
 it may be wise to again add a parallel-friendly API to the library in
 order to allow existing users to convert their code incrementally.
-Alternatively, some advocate use of transactional memory in these cases.
+Alternatively, some advocate using transactional memory in these cases.

Or may be the following?

+Alternatively, some advocate the use of transactional memory in these cases.

Either looks OK to me.

Thanks, Akira

Quoted 8 lines

locking/locking.tex +0 -1
 While the jury is still out on transactional memory,
 Section~\ref{sec:future:Transactional Memory} discusses its strengths and
 weaknesses.
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Paul E. McKenney

2017-10-27 23:24 UTC #3 lore raw

Quoted 29 lines · Akira Yokosawa

Quoted 15 lines · Yubin Ruan
And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644
locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170
Quoted 7 lines
locking/locking.tex +2 -2
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
The talking point here is library function and signal handler. So something like:
(quoted diff) +2 -0
+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.

Quoted 1 line

Thoughts?

I believe that the major problem is that I didn't really specify the situation and constraints. How about the following?

Thanx, Paul

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

commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce

Author: Paul E. McKenney <[email protected]>
Date:   Fri Oct 27 16:21:33 2017 -0700

locking: Clarify explicit avoidance of signal-handler deadlocks

Reported-by Yubin Ruan <[email protected]>

Signed-off-by Paul E. McKenney <[email protected]>

locking/locking.tex +11 -1

index 14db27d1148b..025320b294ed 100644
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
 
-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible
+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:
 
 \begin{enumerate}
 \item	If the application invokes the library function from

Yubin Ruan

author

2017-10-28 13:37 UTC #4 lore raw

Quoted 62 lines · Paul E. McKenney

Quoted 29 lines · Akira Yokosawa
Quoted 15 lines · Yubin Ruan
And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644
locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170
Quoted 7 lines
locking/locking.tex +2 -2
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
The talking point here is library function and signal handler. So something like:
(quoted diff) +2 -0
+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.
Quoted 1 line
Thoughts?
I believe that the major problem is that I didn't really specify the situation and constraints. How about the following?
Thanx, Paul
-----------------------------------------------------------------------
commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
Author: Paul E. McKenney <[email protected]>
Date:   Fri Oct 27 16:21:33 2017 -0700
locking: Clarify explicit avoidance of signal-handler deadlocks
Reported-by Yubin Ruan <[email protected]>
Signed-off-by Paul E. McKenney <[email protected]>
locking/locking.tex +4 -1
index 14db27d1148b..025320b294ed 100644
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
 
-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible

locking/locking.tex locks, the strategies in the next section may prove helpful. · line 2173

Quoted 10 lines

locking/locking.tex +7 -0

+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:
 
 \begin{enumerate}
 \item	If the application invokes the library function from

These all look good to me. Thank you Paul.

Yubin

Paul E. McKenney

2017-10-28 13:17 UTC #5 lore raw

Quoted 70 lines · Yubin Ruan

Quoted 69 lines · Paul E. McKenney
Quoted 29 lines · Akira Yokosawa
Quoted 15 lines · Yubin Ruan
And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644
locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170
Quoted 7 lines
locking/locking.tex +2 -2
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
The talking point here is library function and signal handler. So something like:
(quoted diff) +2 -0
+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.
Quoted 1 line
Thoughts?
I believe that the major problem is that I didn't really specify the situation and constraints. How about the following?
Thanx, Paul
-----------------------------------------------------------------------
commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
Author: Paul E. McKenney <[email protected]>
Date:   Fri Oct 27 16:21:33 2017 -0700
locking: Clarify explicit avoidance of signal-handler deadlocks
Reported-by Yubin Ruan <[email protected]>
Signed-off-by Paul E. McKenney <[email protected]>
locking/locking.tex +11 -1
index 14db27d1148b..025320b294ed 100644
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
 
-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible
+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:
 

Quoted 4 lines

locking/locking.tex locks, the strategies in the next section may prove helpful. · line 2173
Quoted 2 lines
locking/locking.tex +0 -0
 \begin{enumerate}
 \item	If the application invokes the library function from
These all look good to me. Thank you Paul.

Very good, I will push it out. May I have your Acked-by? (As in "Acked-by: Yubin Ruan <[email protected]>".)

(If I don't hear otherwise in about 12 hours, I will just push it out as is.)

Thanx, Paul

Akira Yokosawa

Acked-by

2017-10-28 22:29 UTC #6 lore raw

Quoted 76 lines · Paul E. McKenney

Quoted 70 lines · Yubin Ruan
Quoted 69 lines · Paul E. McKenney
Quoted 29 lines · Akira Yokosawa
Quoted 15 lines · Yubin Ruan
And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644
locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170
Quoted 7 lines
locking/locking.tex +2 -2
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
The talking point here is library function and signal handler. So something like:
(quoted diff) +2 -0
+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.
Quoted 1 line
Thoughts?
I believe that the major problem is that I didn't really specify the situation and constraints. How about the following?
Thanx, Paul
-----------------------------------------------------------------------
commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
Author: Paul E. McKenney <[email protected]>
Date:   Fri Oct 27 16:21:33 2017 -0700
locking: Clarify explicit avoidance of signal-handler deadlocks
Reported-by Yubin Ruan <[email protected]>
Signed-off-by Paul E. McKenney <[email protected]>
locking/locking.tex +11 -1
index 14db27d1148b..025320b294ed 100644
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
 
-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible
+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:
 
Quoted 4 lines
locking/locking.tex locks, the strategies in the next section may prove helpful. · line 2173
Quoted 2 lines
locking/locking.tex +0 -0
 \begin{enumerate}
 \item	If the application invokes the library function from
These all look good to me. Thank you Paul.

Quoted 5 lines

Very good, I will push it out. May I have your Acked-by? (As in "Acked-by: Yubin Ruan <[email protected]>".)
(If I don't hear otherwise in about 12 hours, I will just push it out as is.)

Paul, please append

Acked-by Akira Yokosawa <[email protected]>

Thanks, Akira

Quoted 4 lines

Thanx, Paul

Paul E. McKenney

2017-10-29 03:19 UTC #7 lore raw

Quoted 80 lines · Akira Yokosawa

Quoted 79 lines · Paul E. McKenney
Quoted 70 lines · Yubin Ruan
Quoted 69 lines · Paul E. McKenney
Quoted 29 lines · Akira Yokosawa
Quoted 15 lines · Yubin Ruan
And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644
locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170
Quoted 7 lines
locking/locking.tex +2 -2
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
The talking point here is library function and signal handler. So something like:
(quoted diff) +2 -0
+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.
Quoted 1 line
Thoughts?
I believe that the major problem is that I didn't really specify the situation and constraints. How about the following?
Thanx, Paul
-----------------------------------------------------------------------
commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
Author: Paul E. McKenney <[email protected]>
Date:   Fri Oct 27 16:21:33 2017 -0700
locking: Clarify explicit avoidance of signal-handler deadlocks
Reported-by Yubin Ruan <[email protected]>
Signed-off-by Paul E. McKenney <[email protected]>
locking/locking.tex +11 -1
index 14db27d1148b..025320b294ed 100644
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
 
-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible
+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:
 
Quoted 4 lines
locking/locking.tex locks, the strategies in the next section may prove helpful. · line 2173
Quoted 2 lines
locking/locking.tex +0 -0
 \begin{enumerate}
 \item	If the application invokes the library function from
These all look good to me. Thank you Paul.
Very good, I will push it out. May I have your Acked-by? (As in "Acked-by: Yubin Ruan <[email protected]>".)

Quoted 6 lines

Quoted 2 lines
(If I don't hear otherwise in about 12 hours, I will just push it out as is.)
Paul, please append
Acked-by Akira Yokosawa <[email protected]>

Done, thank you!

Thanx, Paul

Yubin Ruan

author Acked-by

2017-10-29 00:15 UTC #8 lore raw

In reply to Paul E. McKenney

Quoted 76 lines · Paul E. McKenney

Quoted 70 lines · Yubin Ruan
Quoted 69 lines · Paul E. McKenney
Quoted 29 lines · Akira Yokosawa
Quoted 15 lines · Yubin Ruan
And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644
locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170
Quoted 7 lines
locking/locking.tex +2 -2
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
The talking point here is library function and signal handler. So something like:
(quoted diff) +2 -0
+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.
Quoted 1 line
Thoughts?
I believe that the major problem is that I didn't really specify the situation and constraints. How about the following?
Thanx, Paul
-----------------------------------------------------------------------
commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
Author: Paul E. McKenney <[email protected]>
Date:   Fri Oct 27 16:21:33 2017 -0700
locking: Clarify explicit avoidance of signal-handler deadlocks
Reported-by Yubin Ruan <[email protected]>
Signed-off-by Paul E. McKenney <[email protected]>
locking/locking.tex +11 -1
index 14db27d1148b..025320b294ed 100644
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
 
-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible
+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:
 
Quoted 4 lines
locking/locking.tex locks, the strategies in the next section may prove helpful. · line 2173
Quoted 2 lines
locking/locking.tex +0 -0
 \begin{enumerate}
 \item	If the application invokes the library function from
These all look good to me. Thank you Paul.

Quoted 5 lines

Very good, I will push it out. May I have your Acked-by? (As in "Acked-by: Yubin Ruan <[email protected]>".)
(If I don't hear otherwise in about 12 hours, I will just push it out as is.)

Acked-by Yubin Ruan <[email protected]>

Yubin

Paul E. McKenney

Applied

2017-10-29 03:20 UTC #9 lore raw

Quoted 77 lines · Yubin Ruan

Quoted 76 lines · Paul E. McKenney
Quoted 74 lines · Yubin Ruan
Quoted 61 lines · Paul E. McKenney
Quoted 29 lines · Akira Yokosawa
Quoted 15 lines · Yubin Ruan
And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.
Thanks,
Yubin
locking/locking.tex +0 -0
index 14db27d..a9f46f1 100644
locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2170
Quoted 7 lines
locking/locking.tex +2 -2
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
The talking point here is library function and signal handler. So something like:
(quoted diff) +2 -0
+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.
Quoted 1 line
Thoughts?
I believe that the major problem is that I didn't really specify the situation and constraints. How about the following?
Thanx, Paul
-----------------------------------------------------------------------
commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
Author: Paul E. McKenney <[email protected]>
Date:   Fri Oct 27 16:21:33 2017 -0700
locking: Clarify explicit avoidance of signal-handler deadlocks
Reported-by Yubin Ruan <[email protected]>
Signed-off-by Paul E. McKenney <[email protected]>
locking/locking.tex +4 -1
index 14db27d1148b..025320b294ed 100644
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
 
-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible
locking/locking.tex locks, the strategies in the next section may prove helpful. · line 2173
Quoted 10 lines
locking/locking.tex +7 -0
+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:
 
 \begin{enumerate}
 \item	If the application invokes the library function from
These all look good to me. Thank you Paul.

Quoted 8 lines

Quoted 5 lines
Very good, I will push it out. May I have your Acked-by? (As in "Acked-by: Yubin Ruan <[email protected]>".)
(If I don't hear otherwise in about 12 hours, I will just push it out as is.)
Acked-by Yubin Ruan <[email protected]>

Applied, thank you!

Thanx, Paul

Paul E. McKenney

2017-10-27 23:32 UTC #10 lore raw

In reply to Yubin Ruan

Quoted 6 lines · Yubin Ruan

And here are some more modification to some wording in chapter 7, but I am not sure whether you like it or not.
Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a lock primitives with atomic instructions(which is what I was doing) is something that is possible and used in production.

It most certainly is possible, but it is wise less often than it might seem. ;-)

Quoted 2 lines

Thanks,
Yubin

BTW, I cannot accept patches without a valid Signed-off-by. As Akira suggested, please see the FAQ for more details.

locking/locking.tex Signal-handler deadlocks can be explicitly avoided as follows: · line 2171

Quoted 13 lines

locking/locking.tex +2 -2

index 14db27d..a9f46f1 100644
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
 \end{enumerate}

I covered this on in my earlier email.

locking/locking.tex locking's villainy. · line 2335

Quoted 10 lines

locking/locking.tex +1 -1

 These rules can be enforced by using tools similar to

@@ -2329,7 +2329,7 @@ locking's villainy.
 If there are a very large number of uses of a callback-heavy library,
 it may be wise to again add a parallel-friendly API to the library in
 order to allow existing users to convert their code incrementally.
-Alternatively, some advocate use of transactional memory in these cases.
+Alternatively, some advocate using transactional memory in these cases.
 While the jury is still out on transactional memory,
 Section~\ref{sec:future:Transactional Memory} discusses its strengths and
 weaknesses.

And for this one, I am not seeing the problem with the original wording.

Thanx, Paul

Akira Yokosawa

2017-10-27 15:02 UTC #11 lore raw

In reply to Yubin Ruan

Hi Yubin,

Quoted 11 lines · Yubin Ruan

Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644

locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177

Quoted 5 lines

locking/locking-existence.tex +1 -1

@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis

I'd suggest the following:

+These problems can be solved, in fact, and such solutions form the basis

Quoted 9 lines

locking/locking-existence.tex +0 -1
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.

And please refer to Section 1.5 of perfbook for the process of contributing patches.

Here is what Paul told me when I submitted my first patch back in April 2016.

Quoted 5 lines · Paul E. McKenney

Akira, in the future, please do use "git format-patch" and also please use the Linux-kernel preferred format for referencing commits, as shown in the updated commit below. The idea is to use the first 12 digits of the SHA-1 commit ID, followed by the subject line in both quotes and parentheses.

You can see the archive of the thread at:

    http://www.spinics.net/lists/perfbook/msg00148.html

       Thanks, Akira

Paul E. McKenney

2017-10-27 23:05 UTC #12 lore raw

Quoted 22 lines · Akira Yokosawa

Hi Yubin,
Quoted 11 lines · Yubin Ruan
Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644
locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177
Quoted 5 lines
locking/locking-existence.tex +1 -1
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
I'd suggest the following:

Quoted 1 line

+These problems can be solved, in fact, and such solutions form the basis

How about this?

Not only can these problems be solved, but the solutions also form the basis of lock-based software transactional memory [...].

Quoted 22 lines

Quoted 9 lines
locking/locking-existence.tex +0 -1
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
And please refer to Section 1.5 of perfbook for the process of contributing patches.
Here is what Paul told me when I submitted my first patch back in April 2016.
Quoted 5 lines · Paul E. McKenney
Akira, in the future, please do use "git format-patch" and also please use the Linux-kernel preferred format for referencing commits, as shown in the updated commit below. The idea is to use the first 12 digits of the SHA-1 commit ID, followed by the subject line in both quotes and parentheses.

Quoted 3 lines

You can see the archive of the thread at:
    http://www.spinics.net/lists/perfbook/msg00148.html

Please do use this approach if you can, but the delay was instead due to it taking some time for me to see that the sentence could in fact be confusing.

Thanx, Paul

Yubin Ruan

author

2017-10-28 08:06 UTC #13 lore raw

Quoted 23 lines · Paul E. McKenney

Quoted 22 lines · Akira Yokosawa
Hi Yubin,
Quoted 11 lines · Yubin Ruan
Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644
locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177
Quoted 5 lines
locking/locking-existence.tex +1 -1
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
I'd suggest the following:

Quoted 6 lines

Quoted 1 line
+These problems can be solved, in fact, and such solutions form the basis
How about this?
Not only can these problems be solved, but the solutions also form the basis of lock-based software transactional memory [...].

Thanks for your suggestion. I think Akira's approach looks more nature to me. So, let me finish this little patch ;-)

Yubin

--------------------------------------------------------------------------
From aede1ef2fe8c5213c8aec9581192c5915e69010c Mon Sep 17 00:00:00 2001
From: Yubin Ruan <[email protected]>
Date: Sat, 28 Oct 2017 16:00:43 +0800
Subject: [PATCH] locking: a typo fixed

Signed-off-by Yubin Ruan <[email protected]>

---
 locking/locking-existence.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

locking/locking-existence.tex +1 -1

index 9fcbbf9..2be69d8 100644
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved, in fact, and such solutions form the basis
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,

Signature · 1 line

2.7.4

Akira Yokosawa

2017-10-28 01:53 UTC #14 lore raw

Quoted 26 lines · Yubin Ruan

Quoted 25 lines · Paul E. McKenney
Quoted 23 lines · Akira Yokosawa
Hi Yubin,
Quoted 11 lines · Yubin Ruan
Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644
locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177
Quoted 5 lines
locking/locking-existence.tex +1 -1
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
I'd suggest the following:
+These problems can be solved, in fact, and such solutions form the basis

Quoted 7 lines

Quoted 4 lines
How about this?
Not only can these problems be solved, but the solutions also form the basis of lock-based software transactional memory [...].
Thanks for your suggestion. I think Akira's approach looks more nature to me. So, let me finish this little patch ;-)

Well, I think Paul's suggestion is much clearer.

BTW Yubin, your mail has a date field indicating it came from the near future:

Quoted 1 line

Date: Sat, 28 Oct 2017 16:06:40 +0800

May be time zone setting issue?

Thanks, Akira

Quoted 28 lines

Yubin
--------------------------------------------------------------------------
Quoted 1 line
From aede1ef2fe8c5213c8aec9581192c5915e69010c Mon Sep 17 00:00:00 2001
From: Yubin Ruan <[email protected]>
Date: Sat, 28 Oct 2017 16:00:43 +0800
Subject: [PATCH] locking: a typo fixed
Signed-off-by Yubin Ruan <[email protected]>
---
 locking/locking-existence.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
locking/locking-existence.tex +1 -1
index 9fcbbf9..2be69d8 100644
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved, in fact, and such solutions form the basis
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,

Yubin Ruan

author

2017-10-28 09:14 UTC #15 lore raw

Quoted 35 lines · Akira Yokosawa

Quoted 26 lines · Yubin Ruan
Quoted 25 lines · Paul E. McKenney
Quoted 23 lines · Akira Yokosawa
Hi Yubin,
Quoted 11 lines · Yubin Ruan
Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644
locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177
Quoted 5 lines
locking/locking-existence.tex +1 -1
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
I'd suggest the following:
+These problems can be solved, in fact, and such solutions form the basis
Quoted 7 lines
Quoted 4 lines
How about this?
Not only can these problems be solved, but the solutions also form the basis of lock-based software transactional memory [...].
Thanks for your suggestion. I think Akira's approach looks more nature to me. So, let me finish this little patch ;-)

Quoted 7 lines

Well, I think Paul's suggestion is much clearer.
BTW Yubin, your mail has a date field indicating it came from the near future:
Quoted 1 line
Date: Sat, 28 Oct 2017 16:06:40 +0800
May be time zone setting issue?

What time zone should I set?

Yubin

Quoted 26 lines

Quoted 25 lines
--------------------------------------------------------------------------
Quoted 1 line
From aede1ef2fe8c5213c8aec9581192c5915e69010c Mon Sep 17 00:00:00 2001
From: Yubin Ruan <[email protected]>
Date: Sat, 28 Oct 2017 16:00:43 +0800
Subject: [PATCH] locking: a typo fixed
Signed-off-by Yubin Ruan <[email protected]>
---
 locking/locking-existence.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
locking/locking-existence.tex +1 -1
index 9fcbbf9..2be69d8 100644
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved, in fact, and such solutions form the basis
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,

Yubin Ruan

author

2017-10-28 09:16 UTC #16 lore raw

In reply to Akira Yokosawa

Quoted 35 lines · Akira Yokosawa

Quoted 26 lines · Yubin Ruan
Quoted 25 lines · Paul E. McKenney
Quoted 23 lines · Akira Yokosawa
Hi Yubin,
Quoted 11 lines · Yubin Ruan
Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644
locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177
Quoted 5 lines
locking/locking-existence.tex +1 -1
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
I'd suggest the following:
+These problems can be solved, in fact, and such solutions form the basis
Quoted 7 lines
Quoted 4 lines
How about this?
Not only can these problems be solved, but the solutions also form the basis of lock-based software transactional memory [...].
Thanks for your suggestion. I think Akira's approach looks more nature to me. So, let me finish this little patch ;-)

Quoted 7 lines

Well, I think Paul's suggestion is much clearer.
BTW Yubin, your mail has a date field indicating it came from the near future:
Quoted 1 line
Date: Sat, 28 Oct 2017 16:06:40 +0800
May be time zone setting issue?

Thanks Akira, I have correct the time configuration and modify the patch as follow (as suggested by Paul)

Yubin

-----------------------------------------------------------------------
From ae26699b708e3ccb52c134aecf79d64f8e89a23e Mon Sep 17 00:00:00 2001
From: Yubin Ruan <[email protected]>
Date: Sat, 28 Oct 2017 17:15:06 +0800
Subject: [PATCH] locking: a typo fixed

Signed-off-by Yubin Ruan <[email protected]>

---
 locking/locking-existence.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

locking/locking-existence.tex +2 -2

index 9fcbbf9..6340734 100644
@@ -174,8 +174,8 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
-of lock-based software transactional memory
+Not only can these problems be solved, but the solutions also form
+the basis of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,
 Chapter~\ref{chp:Deferred Processing}

Signature · 1 line

2.7.4

Paul E. McKenney

2017-10-28 13:23 UTC #17 lore raw

Quoted 38 lines · Yubin Ruan

Quoted 37 lines · Akira Yokosawa
Quoted 26 lines · Yubin Ruan
Quoted 25 lines · Paul E. McKenney
Quoted 23 lines · Akira Yokosawa
Hi Yubin,
Quoted 11 lines · Yubin Ruan
Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644
locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177
Quoted 5 lines
locking/locking-existence.tex +1 -1
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
I'd suggest the following:
+These problems can be solved, in fact, and such solutions form the basis
Quoted 7 lines
Quoted 4 lines
How about this?
Not only can these problems be solved, but the solutions also form the basis of lock-based software transactional memory [...].
Thanks for your suggestion. I think Akira's approach looks more nature to me. So, let me finish this little patch ;-)
Well, I think Paul's suggestion is much clearer.

Quoted 8 lines

Quoted 5 lines
BTW Yubin, your mail has a date field indicating it came from the near future:
Quoted 1 line
Date: Sat, 28 Oct 2017 16:06:40 +0800
May be time zone setting issue?
Thanks Akira, I have correct the time configuration and modify the patch as follow (as suggested by Paul)

OK, thank you. But the way you say "as suggested by Paul" is as shown below, "Suggested-by". Not at all a big deal in my case, but it is good to get in practice so that you can help other people get patches in while still making sure that they get credit.

Also, could you please use "git format-patch" and "git send-email"? Akira and I can help if the documentation has you confused. In the meantime, here are my notes to myself that I use to send out RCU patches.

If you could redo and resend the patch, I would be very happy to accept it.

------------------------------------------------------------------------
git format-patch -o <dir> -n --subject-prefix="PATCH -tip" <since>[..<until>]

Create an email-ready patch. "-n" says to number them. Use "git send-email" to send them.

For typical RCU patch from tip/core/rcu, something like:

git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/rcu" to-mingo git format-patch -o /tmp/RCU -n --subject-prefix="PATCH RFC tip/core/rcu" to-mingo git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/urgent" to-mingo

For intended submissions, RFC submissions, and bug fixes, respectively.

Then run scripts/checkpatch.pl on each file in /tmp/RCU:

scripts/checkpatch.pl /tmp/RCU/*

git send-email --no-chain-reply-to --to [email protected] --cc email1@address1 --cc email2@address2 file1 file2 ...

For typical RCU patch, check -next conflicts, then something like:

mutt [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -s '[PATCH tip/core/rcu 0/N] @@@title@@@'

Then obtain the message-id of the above email, and:

git send-email --in-reply-to="@@@" --no-thread --to [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] /tmp/RCU/*

# git send-email --in-reply-to="@@@" --no-chain-reply-to --to [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] /tmp/RCU/*
------------------------------------------------------------------------

Quoted 8 lines

Yubin
-----------------------------------------------------------------------
Quoted 1 line
From ae26699b708e3ccb52c134aecf79d64f8e89a23e Mon Sep 17 00:00:00 2001
From: Yubin Ruan <[email protected]>
Date: Sat, 28 Oct 2017 17:15:06 +0800
Subject: [PATCH] locking: a typo fixed

Quoted 23 lines

Signed-off-by Yubin Ruan <[email protected]>

---
 locking/locking-existence.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

locking/locking-existence.tex +2 -2

index 9fcbbf9..6340734 100644
@@ -174,8 +174,8 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
-of lock-based software transactional memory
+Not only can these problems be solved, but the solutions also form
+the basis of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,
 Chapter~\ref{chp:Deferred Processing}

Signature · 1 line

2.7.4

Akira Yokosawa

Acked-by

2017-10-28 23:09 UTC #18 lore raw

Quoted 48 lines · Paul E. McKenney

Quoted 38 lines · Yubin Ruan
Quoted 37 lines · Akira Yokosawa
Quoted 26 lines · Yubin Ruan
Quoted 25 lines · Paul E. McKenney
Quoted 23 lines · Akira Yokosawa
Hi Yubin,
Quoted 11 lines · Yubin Ruan
Hi paul,
I finish chapter 7 and find some typo. Fixed in the patch below.
Yubin
locking/locking-existence.tex +0 -0
index 9fcbbf9..c7c4ae8 100644
locking/locking-existence.tex single partitionable data structure such as the hash table shown in the · line 177
Quoted 5 lines
locking/locking-existence.tex +1 -1
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
I'd suggest the following:
+These problems can be solved, in fact, and such solutions form the basis
Quoted 7 lines
Quoted 4 lines
How about this?
Not only can these problems be solved, but the solutions also form the basis of lock-based software transactional memory [...].
Thanks for your suggestion. I think Akira's approach looks more nature to me. So, let me finish this little patch ;-)
Well, I think Paul's suggestion is much clearer.
Quoted 8 lines
Quoted 5 lines
BTW Yubin, your mail has a date field indicating it came from the near future:
Quoted 1 line
Date: Sat, 28 Oct 2017 16:06:40 +0800
May be time zone setting issue?
Thanks Akira, I have correct the time configuration and modify the patch as follow (as suggested by Paul)

Quoted 7 lines

OK, thank you. But the way you say "as suggested by Paul" is as shown below, "Suggested-by". Not at all a big deal in my case, but it is good to get in practice so that you can help other people get patches in while still making sure that they get credit.
Also, could you please use "git format-patch" and "git send-email"? Akira and I can help if the documentation has you confused.

I'm not sure I can help in the use of "git send-email". Looks like Yubin did use "git format-patch" and appended the patch below the "-----------" line, which is not recognized as scissors by "git am". A line of "----8<-----" could be used instead.

Quoted 29 lines

In the
meantime, here are my notes to myself that I use to send out RCU patches.
If you could redo and resend the patch, I would be very happy to accept it.
------------------------------------------------------------------------
git format-patch -o <dir> -n --subject-prefix="PATCH -tip" <since>[..<until>]
Create an email-ready patch. "-n" says to number them. Use "git send-email" to send them.
For typical RCU patch from tip/core/rcu, something like:
git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/rcu" to-mingo git format-patch -o /tmp/RCU -n --subject-prefix="PATCH RFC tip/core/rcu" to-mingo git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/urgent" to-mingo
For intended submissions, RFC submissions, and bug fixes, respectively.
Then run scripts/checkpatch.pl on each file in /tmp/RCU:
scripts/checkpatch.pl /tmp/RCU/*
git send-email --no-chain-reply-to --to [email protected] --cc email1@address1 --cc email2@address2 file1 file2 ...
For typical RCU patch, check -next conflicts, then something like:

Quoted 16 lines

mutt [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -c [email protected] -s '[PATCH tip/core/rcu 0/N] @@@title@@@'
Then obtain the message-id of the above email, and:
git send-email --in-reply-to="@@@" --no-thread --to [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] /tmp/RCU/*
# git send-email --in-reply-to="@@@" --no-chain-reply-to --to [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] --cc [email protected] /tmp/RCU/*
------------------------------------------------------------------------
Quoted 7 lines
Yubin
-----------------------------------------------------------------------
Quoted 1 line
From ae26699b708e3ccb52c134aecf79d64f8e89a23e Mon Sep 17 00:00:00 2001
From: Yubin Ruan <[email protected]>
Date: Sat, 28 Oct 2017 17:15:06 +0800
Subject: [PATCH] locking: a typo fixed

This change is not a simple "typo fix" any more, so I think the commit title should be reworded to something like "locking: Fix syntactic ambiguity".

And please append my acked-by:

Thanks, Akira

Quoted 2 lines

Quoted 1 line
Suggested-by Paul E. McKenney <[email protected]>

Acked-by Akira Yokosawa <[email protected]>

Quoted 25 lines

Quoted 23 lines

Signed-off-by Yubin Ruan <[email protected]>

---
 locking/locking-existence.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

locking/locking-existence.tex +2 -2

index 9fcbbf9..6340734 100644
@@ -174,8 +174,8 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
-of lock-based software transactional memory
+Not only can these problems be solved, but the solutions also form
+the basis of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,
 Chapter~\ref{chp:Deferred Processing}

Signature · 1 line

2.7.4