On Fri, Mar 2, 2012 at 5:54 PM, <[email protected]> wrote: > > The patch titled > Subject: alpha: fix 32/64-bit bug in futex support > has been added to the -mm tree. Its filename is > alpha-fix-32-64-bit-bug-in-futex-support.patch > > Before you just go and hit "reply", please: > a) Consider who else should be cc'ed > b) Prefer to cc a suitable mailing list as well > c) Ideally: find the original patch on the mailing list and do a > reply-to-all to that, adding suitable additional cc's > > *** Remember to use Documentation/SubmitChecklist when testing your code *** > > The -mm tree is included into linux-next and is updated > there every 3-4 working days > > ------------------------------------------------------ > From: Andrew Morton <[email protected]> > Subject: alpha: fix 32/64-bit bug in futex support > > Michael Cree said: > > : : I have noticed some user space problems (pulseaudio crashes in pthread > : : code, glibc/nptl test suite failures, java compiler freezes on SMP alpha > : : systems) that arise when using a 2.6.39 or later kernel on Alpha. > : : Bisecting between 2.6.38 and 2.6.39 (using glibc/nptl test suite as > : : criterion for good/bad kernel) eventually leads to: > : : > : : 8d7718aa082aaf30a0b4989e1f04858952f941bc is the first bad commit > : : commit 8d7718aa082aaf30a0b4989e1f04858952f941bc > : : Author: Michel Lespinasse <[email protected]> > : : Date: Thu Mar 10 18:50:58 2011 -0800 > : : > : : futex: Sanitize futex ops argument types > : : > : : Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic > : : prototypes to use u32 types for the futex as this is the data type the > : : futex core code uses all over the place. > : : > : : Looking at the commit I see there is a change of the uaddr argument in > : : the Alpha architecture specific code for futexes from int to u32, but I > : : don't see why this should cause a problem. > > Richard Henderson said: > > : futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, > : u32 oldval, u32 newval) > : ... > : : "r"(uaddr), "r"((long)oldval), "r"(newval) > : > : > : There is no 32-bit compare instruction. These are implemented by > : consistently extending the values to a 64-bit type. Since the > : load instruction sign-extends, we want to sign-extend the other > : quantity as well (despite the fact it's logically unsigned). > : > : So: > : > : - : "r"(uaddr), "r"((long)oldval), "r"(newval) > : + : "r"(uaddr), "r"((long)(int)oldval), "r"(newval) > : > : should do the trick. > > Reported-by: Michael Cree <[email protected]> > Tested-by: Michael Cree <[email protected]> > Acked-by: Phil Carmody <[email protected]> > Cc: Richard Henderson <[email protected]> > Cc: Michel Lespinasse <[email protected]> > Cc: Ivan Kokshaysky <[email protected]> > Cc: Matt Turner <[email protected]>
Reviewed-by: Matt Turner <[email protected]> > Cc: <[email protected]> > Signed-off-by: Andrew Morton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
