Messages in this thread | | | Date | Mon, 15 Nov 2004 08:08:36 +0000 | From | Jamie Lokier <> | Subject | Re: Futex queue_me/get_user ordering (was: 2.6.10-rc1-mm5 [u]) |
| |
Chuck Ebbert wrote: > On Sun, 14 Nov 2004 at 09:00:23 +0000 Emergency Services Jamie Lokier wrote: > > >+ * The basic logical guarantee of a futex is that it blocks ONLY > >+ * if cond(var) is known to be true at the time of blocking, for > >+ * any cond. If we queued after testing *uaddr, that would open > >+ * a race condition where we could block indefinitely with > >+ * cond(var) false, which would violate the guarantee. > >+ * > >+ * A consequence is that futex_wait() can return zero and absorb > >+ * a wakeup when *uaddr != val on entry to the syscall. This is > >+ * rare, but normal. > > Why can't it absorb a wakeup and still return -EAGAIN when this happens? > IOW why not apply this patch to the original code? > > out_unqueue: > - /* If we were woken (and unqueued), we succeeded, whatever. */ > - if (!unqueue_me(&q)) > - ret = 0; > + unqueue_me(&q); /* ignore result from unqueue */ > out_release_sem: > up_read(¤t->mm->mmap_sem); > return ret;
Because the number of wakeups reported to FUTEX_WAKE must _exactly_ match the number of wakeups reported to FUTEX_WAIT.
They are like tokens, and for some data structures the return value mustn't be lost or ignored, because that would break structure invariants - such as the matching counters in the pthread condvars which precipitated this thread.
> ...and what is "Emergency Services", BTW?
My little joke, as I wouldn't have known about this if Andrew Morton hadn't forwarded me the message asking about it (I've been away from l-k).
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |