Re: Futex queue_me/get_user ordering

[Hidetoshi Seto]

Jamie Lokier wrote:
> Andrew Morton wrote:
>
> > The patch wasn't supposed to optimise anything.  It fixed a bug which was
> > causing hangs.  See
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm5/broken-out/futex_wait-fix.patch
> >
> > Or are you saying that userspace is buggy??
>
>
> I haven't looked at the NPTL code, but that URL's pseudo-code is buggy.
> The call to FUTEX_WAKE should be doing wake++ conditionally on the
> return value, not unconditionally.
(snip)
> So I don't know if NPTL is buggy, but the pseudo-code given in the bug
> report is (because of unconditional wake++), and so is the failure
> example (because it doesn't use a mutex).
>
> -- Jamie

from glibc-2.3.3(RHEL4b2):

  31 int
  32 __pthread_cond_signal (cond)
  33      pthread_cond_t *cond;
  34 {
  35   /* Make sure we are alone.  */
  36   lll_mutex_lock (cond->__data.__lock);
  37
  38   /* Are there any waiters to be woken?  */
  39   if (cond->__data.__total_seq > cond->__data.__wakeup_seq)
  40     {
  41       /* Yes.  Mark one of them as woken.  */
  42       ++cond->__data.__wakeup_seq;
  43       ++cond->__data.__futex;
  44
  45       /* Wake one.  */
  46       lll_futex_wake (&cond->__data.__futex, 1);
  47     }
  48
  49   /* We are done.  */
  50   lll_mutex_unlock (cond->__data.__lock);
  51
  52   return 0;
  53 }

Ingo, is this buggy?

We should start again with a question:
  Is this a kernel's bug or NPTL's bug?


Thanks,
H.Seto

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/