Re: [RFC] Propose fix for race conditions in pthread cancellation (bz#12683)

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-09-12 at 13:17 -0400, Rich Felker wrote:
> On Fri, Sep 12, 2014 at 06:11:30PM +0200, Torvald Riegel wrote:
> > On Fri, 2014-09-12 at 11:32 -0400, Rich Felker wrote:
> > > On Fri, Sep 12, 2014 at 04:44:26PM +0200, Torvald Riegel wrote:
> > > > On Wed, 2014-09-10 at 18:47 -0300, Adhemerval Zanella wrote:
> > > > "8. Adjust 'lowlevellock.h' arch-specific implementations to provide
> > > > cancelable futex calls (used in libpthread code)."
> > > > 
> > > > Only FUTEX_WAIT should be cancellable, I suppose.
> > > > 
> > > > I've been thinking about whether it would be easier for the
> > > > implementation of cancellable pthreads functions to just call a
> > > > noncancellable FUTEX_WAIT and handle EINTR properly (by not retrying the
> > > > wait but calling pthread_testcancel instead so that any pending
> > > > cancellation is acted upon).  However, this seems to save less
> > > > complexity than just doing for FUTEX_WAIT what we do for all the other
> > > > cancellable syscalls, so it's probably not worth it.
> > > 
> > > This is not viable; it has race conditions, of the exact type which
> > > the futex syscall and the new cancellation system are designed to
> > > avoid.
> > 
> > The new scheme would be used, but would always set the cancellation as
> > pending.  So what I thought about would primarily change the way we act
> > on cancellation, not when it's considered to have happened.  There's no
> > real side effect in waiting, so futex_wait is a special case.
> 
> The problem is that you end up waiting unboundedly long, possibly
> forever. Consider cancellation of a pthread_cond_wait that will never
> be signaled, where the cancellation request arrives in the race
> window.

What I had in mind would interrupt the syscall like the new scheme
proposes to do, so cancellation would happen like in the normal case.
It would not be just checking a flag before/after a syscall.  What would
be different is changing that we just return the EINTR to the calling
pthread code (e.g., the pthread_cond_wait) and letting it do the
cancelling, instead of setting up a pthread_cond_wait-specific
cancellation handler to do that.

But that probably gives too little benefit compared to having a special
case, so I doubt it's worth it.  Nor worth a long discussion I guess :)