All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: Yubin Ruan <ablacktshirt@gmail.com>, perfbook@vger.kernel.org
Subject: Re: [PATCH] typo at Chp 7.
Date: Fri, 27 Oct 2017 16:24:08 -0700	[thread overview]
Message-ID: <20171027232408.GT3659@linux.vnet.ibm.com> (raw)
In-Reply-To: <a15a6a6b-010b-6284-41fb-23ab36a39aa5@gmail.com>

On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
> On 2017/10/27 18:33, Yubin Ruan wrote:
> > 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
> > 
> > diff --git a/locking/locking.tex b/locking/locking.tex
> > index 14db27d..a9f46f1 100644
> > --- a/locking/locking.tex
> > +++ b/locking/locking.tex
> > @@ -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?

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 <paulmck@linux.vnet.ibm.com>
Date:   Fri Oct 27 16:21:33 2017 -0700

    locking: Clarify explicit avoidance of signal-handler deadlocks
    
    Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/locking/locking.tex b/locking/locking.tex
index 14db27d1148b..025320b294ed 100644
--- a/locking/locking.tex
+++ b/locking/locking.tex
@@ -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


  reply	other threads:[~2017-10-27 23:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27  9:23 [PATCH] typo at Chp 7 Yubin Ruan
2017-10-27  9:33 ` Yubin Ruan
2017-10-27 15:18   ` Akira Yokosawa
2017-10-27 23:24     ` Paul E. McKenney [this message]
2017-10-28 13:37       ` Yubin Ruan
2017-10-28 13:17         ` Paul E. McKenney
2017-10-28 22:29           ` Akira Yokosawa
2017-10-29  3:19             ` Paul E. McKenney
2017-10-29  0:15           ` Yubin Ruan
2017-10-29  3:20             ` Paul E. McKenney
2017-10-27 23:32   ` Paul E. McKenney
2017-10-27 15:02 ` Akira Yokosawa
2017-10-27 23:05   ` Paul E. McKenney
2017-10-28  8:06     ` Yubin Ruan
2017-10-28  1:53       ` Akira Yokosawa
2017-10-28  9:14         ` Yubin Ruan
2017-10-28  9:16         ` Yubin Ruan
2017-10-28 13:23           ` Paul E. McKenney
2017-10-28 23:09             ` Akira Yokosawa

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=20171027232408.GT3659@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=ablacktshirt@gmail.com \
    --cc=akiyks@gmail.com \
    --cc=perfbook@vger.kernel.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.