This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Futex error handling

On Thu, Sep 18, 2014 at 07:57:45PM +0200, Torvald Riegel wrote:
> On Thu, 2014-09-18 at 13:39 -0400, Rich Felker wrote:
> > On Thu, Sep 18, 2014 at 02:26:35PM +0200, Torvald Riegel wrote:
> > > > The EFAULT case with
> > > > FUTEX_WAKE, and which I claim FUTEX_WAKE_OP avoids, is when the atomic
> > > > operation on the futex int that's associated with the wake allows
> > > > another thread to synchronize and determine that it may legally
> > > > destroy the object before the actual wake is sent. FUTEX_WAKE_OP can
> > > > fully avoid this by performing the atomic operation after looking up
> > > > and locking the futex hash bucket, so that there's no further access
> > > > after the atomic and thus no opportunity for fault.
> > > 
> > > Agreed; that like what UNLOCK_PI does.  However, and that's something
> > > I've only thought about recently, it would be good to know which
> > > guarantees the kernel gives in this case; in particular, what happens
> > > (and which error code results) if there is destruction and potential
> > > unmapping etc. of the futex variable concurrently with WAKE_OP or
> > > UNLOCK_PI being in flight.
> > 
> > I've RTFS'd and my understanding is that no such problems are
> > possible. The futex hashing (note: there are two futex address
> > arguments and both are hashed, even if they're equal; this should be
> > optimized on the kernel side to make FUTEX_WAKE_OP practical) and
> > locking of the resulting hash buckets happens before the atomic
> > operation is performed. After the atomic operation, the bucket is
> > walked and matching waiters are woken.
> > 
> > In theory it's possible that, as soon as the atomic operation is
> > performed, the backing (file/anon/whatever) is destroyed and its
> > underlying id (e.g. inode number) is reused, so that the backing
> > identified for the original futex address has been reused by this
> > time. However, it's not a problem because a new waiter can't arrive
> > while the hash bucket is still locked -- so such a new waiter can't be
> > woken.
> I don't disagree with what you said (but I haven't looked at all the
> source).  The point I was trying to make was that the current
> implementation is not a guarantee -- if we rely on this then we should
> request the kernel to document that this is allowed usage; that's the
> only way to make sure this keeps working.

Oh, I agree entirely on this. The lack of documentation of the futex
interfaces makes it rather unsafe to rely on _anything_ about it right
now, except for the vague principle that the kernel isn't supposed to
"break userspace" with incompatible changes.

I don't think it will be a problem ggettingthis behavior for
FUTEX_WAKE_OP documented though. It seems like it's part of the
intended semantics.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]