On Sat, Oct 28, 2017 at 09:37:20PM +0800, Yubin Ruan wrote:
> On Fri, Oct 27, 2017 at 04:24:08PM -0700, Paul E. McKenney wrote:
> > 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@xxxxxxxxxxxxxxxxxx>
> > Date: Fri Oct 27 16:21:33 2017 -0700
> >
> > locking: Clarify explicit avoidance of signal-handler deadlocks
> >
> > Reported-by: Yubin Ruan <ablacktshirt@xxxxxxxxx>
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> >
> > 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
>
> 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 <ablacktshirt@xxxxxxxxx>".)
(If I don't hear otherwise in about 12 hours, I will just push it
out as is.)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
