Re: Futex queue_me/get_user ordering

[Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>]

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