Andrew Morton wrote: > iirc we ended up deciding that the futex problems around that time were due > to userspace problems (a version of libc). But then, there's no discussion > around Seto's patch and it didn't get applied. So I don't know what > happened to that work - it's all a bit mysterious.
It can be fixed _either_ in Glibc, or by changing the kernel. That problem is caused by differing assumptions between Glibc and the kernel about subtle futex semantics. Which goes to show they are really clever, or something. I provided pseudo-code for the Glibc fix, but not an actual patch because NPTL is quite complicated and I wanted to know the Glibc people were interested, but apparently they were too busy at the time - benchmarks would have made sense for such a patch. Scott Snyder started fixing part of Glibc, and that did fix his instance of this problem so we know the approach works. But a full patch for Glibc was not prepared. The most recent messages under "Futex queue_me/get_user ordering", with a patch from Jakub Jelinek will fix this problem by changing the kernel. Yes, you should apply Jakub's most recent patch, message-ID "<[EMAIL PROTECTED]>". I have not tested the patch, but it looks convincing. I argued for fixing Glibc on the grounds that the changed kernel behaviour, or more exactly having Glibc depend on it, loses a certain semantic property useful for unusual operations on multiple futexes at the same time. But I appear to have lost the argument, and Jakub's latest patch does clean up some cruft quite nicely, with no expected performance hit. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/