[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Progress on the Alpha distribution at debian-ports



--- On Tue, 2/21/12, Michael Cree <mcree@orcon.net.nz> wrote:
> On 13/02/2012, at 10:56 AM, Bob Tracy wrote:
> >> [2] Provided that you do not use pulseaudio.  If pulseaudio is running
> >> with a newer kernel then iceweasel will crash and will be unuseable.
> > 
> > This is that #$%@! pulseaudio mutex bug we can't seem to get anyone to
> > fix.  There *is* a documented workaround: see Debian bug #649641.
> > Unfortunately, this *does* require building the pulseaudio package from
> > source.
> 
> I've found the bug --- it's in the kernel.  If you are
> building your own kernel then try the attached patch. 
> It should fix the pulseaudio problem (and probably some
> others as well).  The patch is needed for any kernels
> since 2.6.39 and has not been sent upstream yet.

diff --git a/arch/alpha/include/asm/futex.h b/arch/alpha/include/asm/futex.h
index e8a761a..f939794 100644
--- a/arch/alpha/include/asm/futex.h
+++ b/arch/alpha/include/asm/futex.h
@@ -108,7 +108,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
        "       lda     $31,3b-2b(%0)\n"
        "       .previous\n"
        :       "+r"(ret), "=&r"(prev), "=&r"(cmp)
-       :       "r"(uaddr), "r"((long)oldval), "r"(newval)
+       :       "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
        :       "memory");
 
        *uval = prev;


So this fixes an issue introduced here:
"""
commit 8d7718aa082aaf30a0b4989e1f04858952f941bc
Author: Michel Lespinasse <walken@google.com>
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.
"""

and the fix is in cases where we are expecting "sign" (a set bit 31) extension, but are incorrectly getting zero extension?

If so - have the other 64-bit architectures been double-checked to see if they are also victims of this changed-14-architectures-probably-tested-on-only-1 patch? It looks like we were the only arch using a (long) cast, so hopefully we're alone. However, there may be implicit casts in the compiler's asm  itself that are hiding the issue.

Anyway if the author of the above alpha fix is reading, and my interpretation above is correct, he may have at least a Reviewed-by, or even an
Acked-by: Phil Carmody <ext-phil.2.carmody@nokia.com>

Phil


Reply to: