Messages in this thread | | | Date | Mon, 15 Nov 2004 09:58:42 +0900 | From | Hidetoshi Seto <> | Subject | Re: Futex queue_me/get_user ordering |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |