[PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Mikael Pettersson]

Linux/M68K currently doesn't support robust futexes or PI mutexes.
The problem is that the futex code needs to perform certain ops
(cmpxchg, set, add, or, andn, xor) atomically on user-space
addresses, and M68K's lack of a futex.h causes those operations
to be unsupported and disabled.

This patch adds that support, but only for uniprocessor machines,
which is adequate for M68K.  For UP it's enough to disable preemption
to ensure mutual exclusion (futexes don't need to care about other
hardware agents), and the mandatory pagefault_disable() does just that.

This patch is closely based on the one I co-wrote for UP ARM back
in August 2008.  The main change is that this patch uses the C
get_user/put_user accessors instead of inline assembly code with
exception table fixups.

For non-MMU machines the new futex.h simply redirects to the generic
futex.h, so there is no functional change for them.

Tested on aranym with the glibc-2.17 test suite: no regressions, and
a number of mutex/condvar test cases went from failing to succeeding
(tst-mutexpi{5,5a,6,9}, tst-cond2[45], tst-robust[1-9], tst-robustpi[1-8]).
Also tested with glibc-2.18 HEAD and a local glibc patch to enable PI
mutexes: no regressions.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
---
 arch/m68k/include/asm/futex.h |   94 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

--- linux-3.8/arch/m68k/include/asm/futex.h.~1~	1970-01-01 01:00:00.000000000 +0100
+++ linux-3.8/arch/m68k/include/asm/futex.h	2013-02-20 22:07:23.459917612 +0100
@@ -0,0 +1,94 @@
+#ifndef _ASM_M68K_FUTEX_H
+#define _ASM_M68K_FUTEX_H
+
+#ifdef __KERNEL__
+#if !defined(CONFIG_MMU)
+#include <asm-generic/futex.h>
+#else	/* CONFIG_MMU */
+
+#include <linux/futex.h>
+#include <linux/uaccess.h>
+#include <asm/errno.h>
+
+static inline int
+futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
+			      u32 oldval, u32 newval)
+{
+	u32 val;
+
+	if (unlikely(get_user(val, uaddr) != 0))
+		return -EFAULT;
+
+	if (val == oldval && unlikely(put_user(newval, uaddr) != 0))
+		return -EFAULT;
+
+	*uval = val;
+
+	return 0;
+}
+
+static inline int
+futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
+{
+	int op = (encoded_op >> 28) & 7;
+	int cmp = (encoded_op >> 24) & 15;
+	int oparg = (encoded_op << 8) >> 20;
+	int cmparg = (encoded_op << 20) >> 20;
+	int oldval, ret;
+	u32 tmp;
+
+	if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
+		oparg = 1 << oparg;
+
+	pagefault_disable();	/* implies preempt_disable() */
+
+	ret = -EFAULT;
+	if (unlikely(get_user(oldval, uaddr) != 0))
+		goto out_pagefault_enable;
+
+	ret = 0;
+	tmp = oldval;
+
+	switch (op) {
+	case FUTEX_OP_SET:
+		tmp = oparg;
+		break;
+	case FUTEX_OP_ADD:
+		tmp += oparg;
+		break;
+	case FUTEX_OP_OR:
+		tmp |= oparg;
+		break;
+	case FUTEX_OP_ANDN:
+		tmp &= ~oparg;
+		break;
+	case FUTEX_OP_XOR:
+		tmp ^= oparg;
+		break;
+	default:
+		ret = -ENOSYS;
+	}
+
+	if (ret == 0 && unlikely(put_user(tmp, uaddr) != 0))
+		ret = -EFAULT;
+
+out_pagefault_enable:
+	pagefault_enable();	/* subsumes preempt_enable() */
+
+	if (ret == 0) {
+		switch (cmp) {
+		case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
+		case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
+		case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
+		case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
+		case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
+		case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
+		default: ret = -ENOSYS;
+		}
+	}
+	return ret;
+}
+
+#endif /* CONFIG_MMU */
+#endif /* __KERNEL__ */
+#endif /* _ASM_M68K_FUTEX_H */

Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Andreas Schwab]

Geert, please push this to 3.10.

Thanks, Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Geert Uytterhoeven]

Hi Andreas, Mikael,

On Fri, May 17, 2013 at 10:44 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Geert, please push this to 3.10.

Thanks for bringing this under my radar. I completely forgot about this patch,
sorry about that.

This also needs removal of "generic-y += futex.h" from
arch/m68k/include/asm/Kbuild. I'll add that.

Andreas: Can I add your acked-by?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Hi Andreas, Mikael,
>
> On Fri, May 17, 2013 at 10:44 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Geert, please push this to 3.10.
>
> Thanks for bringing this under my radar. I completely forgot about this patch,
> sorry about that.
>
> This also needs removal of "generic-y += futex.h" from
> arch/m68k/include/asm/Kbuild. I'll add that.
>
> Andreas: Can I add your acked-by?

Acked-by: Andreas Schwab <schwab@linux-m68k.org>

Thanks, Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Geert Uytterhoeven]

Hi Mikael,

On Fri, Mar 8, 2013 at 3:03 PM, Mikael Pettersson <mikpe@it.uu.se> wrote:
> Linux/M68K currently doesn't support robust futexes or PI mutexes.
> The problem is that the futex code needs to perform certain ops
> (cmpxchg, set, add, or, andn, xor) atomically on user-space
> addresses, and M68K's lack of a futex.h causes those operations
> to be unsupported and disabled.
>
> This patch adds that support, but only for uniprocessor machines,
> which is adequate for M68K.  For UP it's enough to disable preemption
> to ensure mutual exclusion (futexes don't need to care about other
> hardware agents), and the mandatory pagefault_disable() does just that.
>
> This patch is closely based on the one I co-wrote for UP ARM back
> in August 2008.  The main change is that this patch uses the C
> get_user/put_user accessors instead of inline assembly code with
> exception table fixups.
>
> For non-MMU machines the new futex.h simply redirects to the generic
> futex.h, so there is no functional change for them.
>
> Tested on aranym with the glibc-2.17 test suite: no regressions, and
> a number of mutex/condvar test cases went from failing to succeeding
> (tst-mutexpi{5,5a,6,9}, tst-cond2[45], tst-robust[1-9], tst-robustpi[1-8]).
> Also tested with glibc-2.18 HEAD and a local glibc patch to enable PI
> mutexes: no regressions.

I'm a bit puzzled by this, so see my questions below...

> --- linux-3.8/arch/m68k/include/asm/futex.h.~1~ 1970-01-01 01:00:00.000000000 +0100
> +++ linux-3.8/arch/m68k/include/asm/futex.h     2013-02-20 22:07:23.459917612 +0100
> @@ -0,0 +1,94 @@
> +#ifndef _ASM_M68K_FUTEX_H
> +#define _ASM_M68K_FUTEX_H
> +
> +#ifdef __KERNEL__
> +#if !defined(CONFIG_MMU)
> +#include <asm-generic/futex.h>
> +#else  /* CONFIG_MMU */

Why would you not use the version below on nommu?
It doesn't seem to have any real dependencies on MMU support?
What am I missing?

> +#include <linux/futex.h>
> +#include <linux/uaccess.h>
> +#include <asm/errno.h>
> +
> +static inline int
> +futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
> +                             u32 oldval, u32 newval)
> +{
> +       u32 val;
> +
> +       if (unlikely(get_user(val, uaddr) != 0))
> +               return -EFAULT;
> +
> +       if (val == oldval && unlikely(put_user(newval, uaddr) != 0))
> +               return -EFAULT;
> +
> +       *uval = val;
> +
> +       return 0;
> +}

This is purely generic, so it could move to the asm-generic version,
also fixing blackfin, c6x, metag, openrisc, um, unicore32, and xtensa?

> +static inline int
> +futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
> +{
> +       int op = (encoded_op >> 28) & 7;
> +       int cmp = (encoded_op >> 24) & 15;
> +       int oparg = (encoded_op << 8) >> 20;
> +       int cmparg = (encoded_op << 20) >> 20;
> +       int oldval, ret;
> +       u32 tmp;
> +
> +       if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
> +               oparg = 1 << oparg;
> +
> +       pagefault_disable();    /* implies preempt_disable() */
> +
> +       ret = -EFAULT;
> +       if (unlikely(get_user(oldval, uaddr) != 0))
> +               goto out_pagefault_enable;
> +
> +       ret = 0;
> +       tmp = oldval;
> +
> +       switch (op) {
> +       case FUTEX_OP_SET:
> +               tmp = oparg;
> +               break;
> +       case FUTEX_OP_ADD:
> +               tmp += oparg;
> +               break;
> +       case FUTEX_OP_OR:
> +               tmp |= oparg;
> +               break;
> +       case FUTEX_OP_ANDN:
> +               tmp &= ~oparg;
> +               break;
> +       case FUTEX_OP_XOR:
> +               tmp ^= oparg;
> +               break;
> +       default:
> +               ret = -ENOSYS;
> +       }
> +
> +       if (ret == 0 && unlikely(put_user(tmp, uaddr) != 0))
> +               ret = -EFAULT;
> +
> +out_pagefault_enable:
> +       pagefault_enable();     /* subsumes preempt_enable() */
> +
> +       if (ret == 0) {
> +               switch (cmp) {
> +               case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
> +               case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
> +               case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
> +               case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
> +               case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
> +               case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
> +               default: ret = -ENOSYS;
> +               }
> +       }
> +       return ret;
> +}

This is also purely generic?
Do you know why the current version in asm-generic doesn't do the
{get,put}_user()?

Thanks for your answers!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Mikael Pettersson]

Geert,

Geert Uytterhoeven writes:
 > Hi Mikael,
 > 
 > On Fri, Mar 8, 2013 at 3:03 PM, Mikael Pettersson <mikpe@it.uu.se> wrote:
 > > Linux/M68K currently doesn't support robust futexes or PI mutexes.
 > > The problem is that the futex code needs to perform certain ops
 > > (cmpxchg, set, add, or, andn, xor) atomically on user-space
 > > addresses, and M68K's lack of a futex.h causes those operations
 > > to be unsupported and disabled.
 > >
 > > This patch adds that support, but only for uniprocessor machines,
 > > which is adequate for M68K.  For UP it's enough to disable preemption
 > > to ensure mutual exclusion (futexes don't need to care about other
 > > hardware agents), and the mandatory pagefault_disable() does just that.
 > >
 > > This patch is closely based on the one I co-wrote for UP ARM back
 > > in August 2008.  The main change is that this patch uses the C
 > > get_user/put_user accessors instead of inline assembly code with
 > > exception table fixups.
 > >
 > > For non-MMU machines the new futex.h simply redirects to the generic
 > > futex.h, so there is no functional change for them.
 > >
 > > Tested on aranym with the glibc-2.17 test suite: no regressions, and
 > > a number of mutex/condvar test cases went from failing to succeeding
 > > (tst-mutexpi{5,5a,6,9}, tst-cond2[45], tst-robust[1-9], tst-robustpi[1-8]).
 > > Also tested with glibc-2.18 HEAD and a local glibc patch to enable PI
 > > mutexes: no regressions.
 > 
 > I'm a bit puzzled by this, so see my questions below...
 > 
 > > --- linux-3.8/arch/m68k/include/asm/futex.h.~1~ 1970-01-01 01:00:00.000000000 +0100
 > > +++ linux-3.8/arch/m68k/include/asm/futex.h     2013-02-20 22:07:23.459917612 +0100
 > > @@ -0,0 +1,94 @@
 > > +#ifndef _ASM_M68K_FUTEX_H
 > > +#define _ASM_M68K_FUTEX_H
 > > +
 > > +#ifdef __KERNEL__
 > > +#if !defined(CONFIG_MMU)
 > > +#include <asm-generic/futex.h>
 > > +#else  /* CONFIG_MMU */
 > 
 > Why would you not use the version below on nommu?
 > It doesn't seem to have any real dependencies on MMU support?
 > What am I missing?

The only reason I don't handle no-MMU is that I don't know how much
no-MMU butchers the semantics of the various primitives (mainly the
user-space accessors).

Does no-MMU pagefault_disable() disable preemption?  This code
relies on that.

 > > +#include <linux/futex.h>
 > > +#include <linux/uaccess.h>
 > > +#include <asm/errno.h>
 > > +
 > > +static inline int
 > > +futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 > > +                             u32 oldval, u32 newval)
 > > +{
 > > +       u32 val;
 > > +
 > > +       if (unlikely(get_user(val, uaddr) != 0))
 > > +               return -EFAULT;
 > > +
 > > +       if (val == oldval && unlikely(put_user(newval, uaddr) != 0))
 > > +               return -EFAULT;
 > > +
 > > +       *uval = val;
 > > +
 > > +       return 0;
 > > +}
 > 
 > This is purely generic, so it could move to the asm-generic version,
 > also fixing blackfin, c6x, metag, openrisc, um, unicore32, and xtensa?

Yes it should be put somewhere generic, but I don't want to have to
investigate each and every arch to guess if they can safely use this
version or not.  I'd rather put this somewhere alongside the stub futex.h
and have other archs opt-in at the discretion of their maintainers.

Put it in asm-generic as futex-nostub.h or futex-mmu.h or something like that?

Some of the other archs are no-MMU: see above for my concerns about that.

 > > +static inline int
 > > +futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
 > > +{
 > > +       int op = (encoded_op >> 28) & 7;
 > > +       int cmp = (encoded_op >> 24) & 15;
 > > +       int oparg = (encoded_op << 8) >> 20;
 > > +       int cmparg = (encoded_op << 20) >> 20;
 > > +       int oldval, ret;
 > > +       u32 tmp;
 > > +
 > > +       if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
 > > +               oparg = 1 << oparg;
 > > +
 > > +       pagefault_disable();    /* implies preempt_disable() */
 > > +
 > > +       ret = -EFAULT;
 > > +       if (unlikely(get_user(oldval, uaddr) != 0))
 > > +               goto out_pagefault_enable;
 > > +
 > > +       ret = 0;
 > > +       tmp = oldval;
 > > +
 > > +       switch (op) {
 > > +       case FUTEX_OP_SET:
 > > +               tmp = oparg;
 > > +               break;
 > > +       case FUTEX_OP_ADD:
 > > +               tmp += oparg;
 > > +               break;
 > > +       case FUTEX_OP_OR:
 > > +               tmp |= oparg;
 > > +               break;
 > > +       case FUTEX_OP_ANDN:
 > > +               tmp &= ~oparg;
 > > +               break;
 > > +       case FUTEX_OP_XOR:
 > > +               tmp ^= oparg;
 > > +               break;
 > > +       default:
 > > +               ret = -ENOSYS;
 > > +       }
 > > +
 > > +       if (ret == 0 && unlikely(put_user(tmp, uaddr) != 0))
 > > +               ret = -EFAULT;
 > > +
 > > +out_pagefault_enable:
 > > +       pagefault_enable();     /* subsumes preempt_enable() */
 > > +
 > > +       if (ret == 0) {
 > > +               switch (cmp) {
 > > +               case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
 > > +               case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
 > > +               case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
 > > +               case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
 > > +               case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
 > > +               case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
 > > +               default: ret = -ENOSYS;
 > > +               }
 > > +       }
 > > +       return ret;
 > > +}
 > 
 > This is also purely generic?
 > Do you know why the current version in asm-generic doesn't do the
 > {get,put}_user()?

I don't know the history of the asm-generic version; I guess it was put there
during initial futex development as a template for archs with fully-featured
atomics to instantiate and optimize.

/Mikael

Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Geert Uytterhoeven]

On Fri, May 17, 2013 at 2:05 PM, Mikael Pettersson <mikpe@it.uu.se> wrote:
>  > > --- linux-3.8/arch/m68k/include/asm/futex.h.~1~ 1970-01-01 01:00:00.000000000 +0100
>  > > +++ linux-3.8/arch/m68k/include/asm/futex.h     2013-02-20 22:07:23.459917612 +0100
>  > > @@ -0,0 +1,94 @@
>  > > +#ifndef _ASM_M68K_FUTEX_H
>  > > +#define _ASM_M68K_FUTEX_H
>  > > +
>  > > +#ifdef __KERNEL__
>  > > +#if !defined(CONFIG_MMU)
>  > > +#include <asm-generic/futex.h>
>  > > +#else  /* CONFIG_MMU */
>  >
>  > Why would you not use the version below on nommu?
>  > It doesn't seem to have any real dependencies on MMU support?
>  > What am I missing?
>
> The only reason I don't handle no-MMU is that I don't know how much
> no-MMU butchers the semantics of the various primitives (mainly the
> user-space accessors).

The userspace accessors shouldn't matter much, I think.

> Does no-MMU pagefault_disable() disable preemption?  This code
> relies on that.

It seems it does.

>  > > +#include <linux/futex.h>
>  > > +#include <linux/uaccess.h>
>  > > +#include <asm/errno.h>
>  > > +
>  > > +static inline int
>  > > +futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
>  > > +                             u32 oldval, u32 newval)
>  > > +{
>  > > +       u32 val;
>  > > +
>  > > +       if (unlikely(get_user(val, uaddr) != 0))
>  > > +               return -EFAULT;
>  > > +
>  > > +       if (val == oldval && unlikely(put_user(newval, uaddr) != 0))
>  > > +               return -EFAULT;
>  > > +
>  > > +       *uval = val;
>  > > +
>  > > +       return 0;
>  > > +}
>  >
>  > This is purely generic, so it could move to the asm-generic version,
>  > also fixing blackfin, c6x, metag, openrisc, um, unicore32, and xtensa?
>
> Yes it should be put somewhere generic, but I don't want to have to
> investigate each and every arch to guess if they can safely use this
> version or not.  I'd rather put this somewhere alongside the stub futex.h
> and have other archs opt-in at the discretion of their maintainers.

Anyway, the m68k version is now in mainline, so I'll let the uClinux people
decide the rest...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Finn Thain]

Hi all,

This patch (which first appeared in 3.10) consistently causes a boot crash 
on 68030.

I used git bisect to isolate the offending commit, which turned out to be
[e4f2dfbb5e92be4e46c0625f4f8eb101110f756f] m68k: implement futex.h to 
support userspace robust futexes and PI mutexes

Recently there have been several bug reports from end users and some 
inconclusive discussion on debian-68k:
http://lists.debian.org/debian-68k/2013/11/msg00144.html
http://lists.debian.org/debian-68k/2013/10/msg00085.html

Anyone have any suggestions? I'm out of ideas.

Finn


Data read fault at 0x00000000 in Super Data (pc=0x3afec)
BAD KERNEL BUSERR
Oops: 00000000
Modules linked in:
PC: [<0003afec>] cmpxchg_futex_value_locked+0x14/0x4a
SR: 2004  SP: 0082fed4  a2: 0082c000
d0: 00000000    d1: 00000001    d2: 00000018    d3: 00000000
d4: 00000061    d5: 00001000    a0: 00000000    a1: 0082e000
Process swapper (pid: 1, task=0082c000)
Frame format=B ssw=074d isc=4a80 isb=661c daddr=00000000 dobuf=00000001
baddr=0003aff2 dibuf=00000000 ver=f
Stack from 0082ff5c:
        002b8cb8 0082ff70 00000000 00000000 00000000 00000000 00000000 000020ac
        00000018 00000007 00000061 00001000 00000000 00000000 002cab50 00002008
        002b3a56 002b8ca4 0082c3f0 00000000 0082c53c 001e316a 00000000 00000000
        001e3172 001e316a 000025d4 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 20000000
        00000000
Call Trace: [<002b8cb8>] futex_init+0x14/0x54
 [<000020ac>] do_one_initcall+0xa4/0x144
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00002008>] do_one_initcall+0x0/0x144
 [<002b3a56>] kernel_init_freeable+0xca/0x152
 [<002b8ca4>] futex_init+0x0/0x54
 [<001e316a>] kernel_init+0x0/0xc8
 [<001e3172>] kernel_init+0x8/0xc8
 [<001e316a>] kernel_init+0x0/0xc8
 [<000025d4>] ret_from_kernel_thread+0xc/0x14


On Fri, 8 Mar 2013, Mikael Pettersson wrote:

> Linux/M68K currently doesn't support robust futexes or PI mutexes.
> The problem is that the futex code needs to perform certain ops
> (cmpxchg, set, add, or, andn, xor) atomically on user-space
> addresses, and M68K's lack of a futex.h causes those operations
> to be unsupported and disabled.
> 
> This patch adds that support, but only for uniprocessor machines,
> which is adequate for M68K.  For UP it's enough to disable preemption
> to ensure mutual exclusion (futexes don't need to care about other
> hardware agents), and the mandatory pagefault_disable() does just that.
> 
> This patch is closely based on the one I co-wrote for UP ARM back
> in August 2008.  The main change is that this patch uses the C
> get_user/put_user accessors instead of inline assembly code with
> exception table fixups.
> 
> For non-MMU machines the new futex.h simply redirects to the generic
> futex.h, so there is no functional change for them.
> 
> Tested on aranym with the glibc-2.17 test suite: no regressions, and
> a number of mutex/condvar test cases went from failing to succeeding
> (tst-mutexpi{5,5a,6,9}, tst-cond2[45], tst-robust[1-9], tst-robustpi[1-8]).
> Also tested with glibc-2.18 HEAD and a local glibc patch to enable PI
> mutexes: no regressions.
> 
> Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
> ---
>  arch/m68k/include/asm/futex.h |   94 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 94 insertions(+)
> 
> --- linux-3.8/arch/m68k/include/asm/futex.h.~1~	1970-01-01 01:00:00.000000000 +0100
> +++ linux-3.8/arch/m68k/include/asm/futex.h	2013-02-20 22:07:23.459917612 +0100
> @@ -0,0 +1,94 @@
> +#ifndef _ASM_M68K_FUTEX_H
> +#define _ASM_M68K_FUTEX_H
> +
> +#ifdef __KERNEL__
> +#if !defined(CONFIG_MMU)
> +#include <asm-generic/futex.h>
> +#else	/* CONFIG_MMU */
> +
> +#include <linux/futex.h>
> +#include <linux/uaccess.h>
> +#include <asm/errno.h>
> +
> +static inline int
> +futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
> +			      u32 oldval, u32 newval)
> +{
> +	u32 val;
> +
> +	if (unlikely(get_user(val, uaddr) != 0))
> +		return -EFAULT;
> +
> +	if (val == oldval && unlikely(put_user(newval, uaddr) != 0))
> +		return -EFAULT;
> +
> +	*uval = val;
> +
> +	return 0;
> +}
> +
> +static inline int
> +futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
> +{
> +	int op = (encoded_op >> 28) & 7;
> +	int cmp = (encoded_op >> 24) & 15;
> +	int oparg = (encoded_op << 8) >> 20;
> +	int cmparg = (encoded_op << 20) >> 20;
> +	int oldval, ret;
> +	u32 tmp;
> +
> +	if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
> +		oparg = 1 << oparg;
> +
> +	pagefault_disable();	/* implies preempt_disable() */
> +
> +	ret = -EFAULT;
> +	if (unlikely(get_user(oldval, uaddr) != 0))
> +		goto out_pagefault_enable;
> +
> +	ret = 0;
> +	tmp = oldval;
> +
> +	switch (op) {
> +	case FUTEX_OP_SET:
> +		tmp = oparg;
> +		break;
> +	case FUTEX_OP_ADD:
> +		tmp += oparg;
> +		break;
> +	case FUTEX_OP_OR:
> +		tmp |= oparg;
> +		break;
> +	case FUTEX_OP_ANDN:
> +		tmp &= ~oparg;
> +		break;
> +	case FUTEX_OP_XOR:
> +		tmp ^= oparg;
> +		break;
> +	default:
> +		ret = -ENOSYS;
> +	}
> +
> +	if (ret == 0 && unlikely(put_user(tmp, uaddr) != 0))
> +		ret = -EFAULT;
> +
> +out_pagefault_enable:
> +	pagefault_enable();	/* subsumes preempt_enable() */
> +
> +	if (ret == 0) {
> +		switch (cmp) {
> +		case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
> +		case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
> +		case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
> +		case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
> +		case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
> +		case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
> +		default: ret = -ENOSYS;
> +		}
> +	}
> +	return ret;
> +}
> +
> +#endif /* CONFIG_MMU */
> +#endif /* __KERNEL__ */
> +#endif /* _ASM_M68K_FUTEX_H */

Re: Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Andreas Schwab]

Finn Thain <fthain@telegraphics.com.au> writes:

> Data read fault at 0x00000000 in Super Data (pc=0x3afec)
> BAD KERNEL BUSERR
> Oops: 00000000
> Modules linked in:
> PC: [<0003afec>] cmpxchg_futex_value_locked+0x14/0x4a

What does it do here?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Finn Thain]

On Tue, 10 Dec 2013, Andreas Schwab wrote:

> Finn Thain <fthain@telegraphics.com.au> writes:
> 
> > Data read fault at 0x00000000 in Super Data (pc=0x3afec)
> > BAD KERNEL BUSERR
> > Oops: 00000000
> > Modules linked in:
> > PC: [<0003afec>] cmpxchg_futex_value_locked+0x14/0x4a
> 
> What does it do here?

What happens next is that swapper dies leading to panic (see below).

It appears that the call graph looks like this,

futex_init()
  cmpxchg_futex_value_locked(&curval, NULL, 0, 0)
    pagefault_disable();
    futex_atomic_cmpxchg_inatomic(curval, NULL, 0, 0)
      get_user(val, NULL)

That is, futex_init() passes a NULL pointer expecting it to fault, as 
described in the comments in kernel/futex.c. Clearly the fault is not 
expected to be fatal.

Finn


MacLinux

 vidaddr: 60040000
  _stext: 00001000
bootinfo: 002CC000
   cpuid: 00000000
 sccbase: 50F04000

ABCFGHIJK
Linux version 3.10.0-rc2-mac-111606-ge4f2dfb (fthain@nippy) (gcc version 
4.4.6 (GCC) ) #14 Tue Dec 10 11:31:21 EST 2013
bootconsole [early0] enabled
Detected Macintosh model: 33
VIA1 at 50f00000 is a 6522 or clone
VIA2 at 50f02000 is a 6522 or clone
Apple Macintosh PowerBook 180
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 3045
Kernel command line: console=ttyS0
PID hash table entries: 64 (order: -4, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Sorting __ex_table...
Memory: 9252k/9252k available (1948k kernel code, 984k data, 104k init)
Virtual kernel memory layout:
    vector  : 0x0029318c - 0x0029358c   (   1 KiB)
    kmap    : 0xd0000000 - 0xf0000000   ( 512 MiB)
    vmalloc : 0x01000000 - 0xd0000000   (3312 MiB)
    lowmem  : 0x00000000 - 0x00c00000   (  12 MiB)
      .init : 0x002b2000 - 0x002cc000   ( 104 KiB)
      .text : 0x00001000 - 0x001e71aa   (1945 KiB)
      .data : 0x001e9d60 - 0x002b11d0   ( 798 KiB)
      .bss  : 0x00292f80 - 0x002b11d0   ( 121 KiB)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
NR_IRQS:72
Killing onboard sonic... Done.
WARNING: Persistent clock returned invalid value!
         Check your CMOS/BIOS settings.
Console: colour dummy device 80x25
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
Calibrating delay loop... 7.83 BogoMIPS (lpj=39168)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
devtmpfs: initialized
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
NuBus: Scanning NuBus slots.
SCSI subsystem initialized
NET: Registered protocol family 2
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Data read fault at 0x00000000 in Super Data (pc=0x3afec)
BAD KERNEL BUSERR
Oops: 00000000
Modules linked in:
PC: [<0003afec>] cmpxchg_futex_value_locked+0x14/0x4a
SR: 2004  SP: 0082fed4  a2: 0082c000
d0: 00000000    d1: 00000001    d2: 00000018    d3: 00000000
d4: 00000061    d5: 00001000    a0: 00000000    a1: 0082e000
Process swapper (pid: 1, task=0082c000)
Frame format=B ssw=074d isc=4a80 isb=661c daddr=00000000 dobuf=00000001
baddr=0003aff2 dibuf=00000000 ver=f
Stack from 0082ff5c:
        002b8cb8 0082ff70 00000000 00000000 00000000 00000000 00000000 000020ac
        00000018 00000007 00000061 00001000 00000000 00000000 002cab50 00002008
        002b3a56 002b8ca4 0082c3f0 00000000 0082c53c 001e316a 00000000 00000000
        001e3172 001e316a 000025d4 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 20000000
        00000000
Call Trace: [<002b8cb8>] futex_init+0x14/0x54
 [<000020ac>] do_one_initcall+0xa4/0x144
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00002008>] do_one_initcall+0x0/0x144
 [<002b3a56>] kernel_init_freeable+0xca/0x152
 [<002b8ca4>] futex_init+0x0/0x54
 [<001e316a>] kernel_init+0x0/0xc8
 [<001e3172>] kernel_init+0x8/0xc8
 [<001e316a>] kernel_init+0x0/0xc8
 [<000025d4>] ret_from_kernel_thread+0xc/0x14

Code: 200f 0280 ffff e000 2240 52a9 0010 4280 <0e90> 1000 4a80 661c b2af 
000c 660c 226f 0010 0e90 9800 4a80 660a 206f 0004 2081
Disabling lock debugging due to kernel taint
note: swapper[1] exited with preempt_count 1
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Re: Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Geert Uytterhoeven]

On Tue, Dec 10, 2013 at 1:54 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> futex_init()
>   cmpxchg_futex_value_locked(&curval, NULL, 0, 0)
>     pagefault_disable();
>     futex_atomic_cmpxchg_inatomic(curval, NULL, 0, 0)
>       get_user(val, NULL)
>
> That is, futex_init() passes a NULL pointer expecting it to fault, as
> described in the comments in kernel/futex.c. Clearly the fault is not
> expected to be fatal.

I added some debugging (basically enabling DEBUG in
arch/m68k/kernel/traps.c, but dependent on a flag that's set to 1 in
futex_init(), and a check in do_page_fault()), and ran it on ARAnyM,
to get a grasp of what's happening on '040:

futex_atomic_cmpxchg_inatomic:20
*** Bus Error *** Format is 7
ssw=0x505, fa=0x0
wb1s=0x0, wb2s=0x0, wb3s=0x0
wb2a=0, wb3a=0, wb2d=0, wb3d=0
mmusr = 800
in_atomic() = 1
mm =   (null)
no_context
send_fault_sig:   (null),7,0
do_page_fault() !=0
.. disabling wb2

Summarized: access_error040() calls do_page_fault(), which just sends
SIGBUS (7), as in_atomic() is 1.

> Data read fault at 0x00000000 in Super Data (pc=0x3afec)
> BAD KERNEL BUSERR

On '030, the relevant code is:

    if (mmusr & (MMU_I | MMU_WP)) {
            if (ssw & 4) {
                    printk("Data %s fault at %#010lx in %s (pc=%#lx)\n",
                           ssw & RW ? "read" : "write",
                           fp->un.fmtb.daddr,
                           space_names[ssw & DFC], fp->ptregs.pc);
                    goto buserr;
            }
            /* Don't try to do anything further if an exception was
               handled. */
            if (do_page_fault (&fp->ptregs, addr, errorcode) < 0)
                    return;

But we never get to do_page_fault(), as ssw = 5 (SUPER_DATA).

The "if (ssw & 4) { ... }" chunk was added in commit
e48d483d581278fae02a5fffeba2b1fef47be4d4 (from full-history-linux):

Author: Andrew Morton <akpm@osdl.org>
Date:   Sun Jan 18 18:32:30 2004 -0800

    [PATCH] M68k RMW accesses

    From: Geert Uytterhoeven <geert@linux-m68k.org>

    M68k: Avoid bus fault for certain RMW accesses (from Roman Zippel)

Which originates from a CVS commit in 2003, based on v2 (v1 didn't have
the chunk) of a patch in the thread "RMW instructions on
MC68020/MC68851 combo..." between Kars and Roman Z.

I guess this case will work(TM) if you remove that chunk again?
But what are the other implications of that?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

>> Data read fault at 0x00000000 in Super Data (pc=0x3afec)
>> BAD KERNEL BUSERR

I think futex_init needs to do set_fs(USER_DS), since futex is about
user data.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

futex_init() vs. KERNEL_DS, was Re: Boot crash on 68030

[Finn Thain]

On Tue, 10 Dec 2013, Andreas Schwab wrote:

> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> 
> >> Data read fault at 0x00000000 in Super Data (pc=0x3afec) BAD KERNEL 
> >> BUSERR
> 
> I think futex_init needs to do set_fs(USER_DS), since futex is about 
> user data.

Rhetorical question: does it make sense to explicitly switch to USER_DS 
when we know that current->mm may be invalid at the time?

Given that the presence of USER_DS or KERNEL_DS at initcall-time varies 
between architectures, perhaps this question must be left to arch 
implementors.

Moreover, architectures that have no need for a run-time test for usable 
futex_value ops have no real interest in such questions. AFAICT, only mips 
needs the run-time test.

For every other arch the availability of futex_value ops is known at 
compile-time. We don't need to pursue universal answers to questions like 
these:

1) the correctness of switching to USER_DS with mm->current == NULL [1]

2) the correctness of USER_DS vs. KERNEL_DS for (all) initcalls [2]

3) the correctness of allowing faults when get_fs() == KERNEL_DS [3]

4) the proposition that "[futex_value ops] explicitly take a __user 
   pointer and are expected to do whatever is needed to perform the 
   operation"  ... even during kernel initialization. [4]

The discussion of these questions in various threads on various lists did 
not resolve anything. Again, this is probably because all of these 
questions are actually arch implementation issues.

So it seems to me that the solution to the futex_init() problem is to 
evaluate the futex_cmpxchg_enabled assignment at compile-time where 
possible, and use the run-time test only on mips. Thoughts?

Finn


[1] http://marc.info/?l=linux-next&m=138876015228975&w=2

[2] https://lkml.org/lkml/2014/1/15/476
    http://marc.info/?l=linux-kernel&m=138971456630101&w=2

[3] http://marc.info/?l=linux-next&m=138876367730190&w=2

[4] http://marc.info/?l=linux-kernel&m=138970641726884&w=2

Re: futex_init() vs. KERNEL_DS, was Re: Boot crash on 68030

[Heiko Carstens]

On Fri, Feb 28, 2014 at 02:12:22PM +1100, Finn Thain wrote:
> > >> Data read fault at 0x00000000 in Super Data (pc=0x3afec) BAD KERNEL 
> > >> BUSERR
> > 
> > I think futex_init needs to do set_fs(USER_DS), since futex is about 
> > user data.
> 
> Rhetorical question: does it make sense to explicitly switch to USER_DS 
> when we know that current->mm may be invalid at the time?
> 
> Given that the presence of USER_DS or KERNEL_DS at initcall-time varies 
> between architectures, perhaps this question must be left to arch 
> implementors.

All architectures start with KERNEL_DS, otherwise the first couple of system
calls within kernel_init() would all fail and the system wouldn't boot.

> Moreover, architectures that have no need for a run-time test for usable 
> futex_value ops have no real interest in such questions. AFAICT, only mips 
> needs the run-time test.
> 
> For every other arch the availability of futex_value ops is known at 
> compile-time. We don't need to pursue universal answers to questions like 
> these:
> 
> 1) the correctness of switching to USER_DS with mm->current == NULL [1]

I "fixed" s390, so it should survive an early switch to USER_DS and a
subsequent failing user space access now.

Anyway,

> The discussion of these questions in various threads on various lists did 
> not resolve anything. Again, this is probably because all of these 
> questions are actually arch implementation issues.
> 
> So it seems to me that the solution to the futex_init() problem is to 
> evaluate the futex_cmpxchg_enabled assignment at compile-time where 
> possible, and use the run-time test only on mips. Thoughts?

Such a patch exists already (bottom of message):

http://marc.info/?l=linux-next&m=138875880028607&w=2

Re: futex_init() vs. KERNEL_DS, was Re: Boot crash on 68030

[Finn Thain]

On Fri, 28 Feb 2014, Heiko Carstens wrote:

> On Fri, Feb 28, 2014 at 02:12:22PM +1100, Finn Thain wrote:
> > > > > Data read fault at 0x00000000 in Super Data (pc=0x3afec) BAD 
> > > > > KERNEL BUSERR
> > > 
> > > I think futex_init needs to do set_fs(USER_DS), since futex is about 
> > > user data.
> > 
> > Rhetorical question: does it make sense to explicitly switch to 
> > USER_DS when we know that current->mm may be invalid at the time?
> > 
> > Given that the presence of USER_DS or KERNEL_DS at initcall-time 
> > varies between architectures, perhaps this question must be left to 
> > arch implementors.
> 
> All architectures start with KERNEL_DS, otherwise the first couple of 
> system calls within kernel_init() would all fail and the system wouldn't 
> boot.

I was alluding to the assertion that "USER_DS is the normal operating 
state": https://lkml.org/lkml/2014/1/15/476

> 
> > Moreover, architectures that have no need for a run-time test for 
> > usable futex_value ops have no real interest in such questions. 
> > AFAICT, only mips needs the run-time test.
> > 
> > For every other arch the availability of futex_value ops is known at 
> > compile-time. We don't need to pursue universal answers to questions 
> > like these:
> > 
> > 1) the correctness of switching to USER_DS with mm->current == NULL
> 
> I "fixed" s390, so it should survive an early switch to USER_DS and a 
> subsequent failing user space access now.
> 
> Anyway,
> 
> > The discussion of these questions in various threads on various lists 
> > did not resolve anything. Again, this is probably because all of these 
> > questions are actually arch implementation issues.
> > 
> > So it seems to me that the solution to the futex_init() problem is to 
> > evaluate the futex_cmpxchg_enabled assignment at compile-time where 
> > possible, and use the run-time test only on mips. Thoughts?
> 
> Such a patch exists already (bottom of message):
> 
> http://marc.info/?l=linux-next&m=138875880028607&w=2
> 

Thanks. I gather that you don't need this patch on s390 any more. Though 
it does promise to save some cycles on any architecture that can optimize 
away all the "if (!futex_cmpxchg_enabled) return" tests.

With your patch, the nak'd patch* from Geert would be obsolete unless it 
was useful to mips (or deemed correct by fiat).

Finn


* http://marc.info/?l=linux-kernel&m=138675863423989&w=2

Re: Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Finn Thain]

On Tue, 10 Dec 2013, Geert Uytterhoeven wrote:

> On '030, the relevant code is:
> 
>     if (mmusr & (MMU_I | MMU_WP)) {
>             if (ssw & 4) {
>                     printk("Data %s fault at %#010lx in %s (pc=%#lx)\n",
>                            ssw & RW ? "read" : "write",
>                            fp->un.fmtb.daddr,
>                            space_names[ssw & DFC], fp->ptregs.pc);
>                     goto buserr;
>             }
>             /* Don't try to do anything further if an exception was
>                handled. */
>             if (do_page_fault (&fp->ptregs, addr, errorcode) < 0)
>                     return;
> 
> But we never get to do_page_fault(), as ssw = 5 (SUPER_DATA).
> 
> The "if (ssw & 4) { ... }" chunk was added in commit 
> e48d483d581278fae02a5fffeba2b1fef47be4d4 (from full-history-linux):

The entire commit can be found here as well, 
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/arch/m68k/kernel/traps.c?id=cf9c906f8eb31033b39f47b4313f7228dc5aa201

> Which originates from a CVS commit in 2003, based on v2 (v1 didn't have 
> the chunk) of a patch in the thread "RMW instructions on MC68020/MC68851 
> combo..." between Kars and Roman Z.
> 
> I guess this case will work(TM) if you remove that chunk again? But what 
> are the other implications of that?

So how shall we understand the intention of that patch? Here's the new 
logic:

	if (mmusr & (MMU_I | MMU_WP)) {
		if (ssw & 4) {
			...
		}
		...
	} else if (!(mmusr & MMU_I)) {
		/* propably a 020 cas fault */
		...
	} else if (mmusr & (MMU_B|MMU_L|MMU_S)) {
		...
	} else {
		...
	}

Seems to me that everything after the first else clause is dead code.

Finn

Re: Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On '030, the relevant code is:
>
>     if (mmusr & (MMU_I | MMU_WP)) {
>             if (ssw & 4) {
>                     printk("Data %s fault at %#010lx in %s (pc=%#lx)\n",
>                            ssw & RW ? "read" : "write",
>                            fp->un.fmtb.daddr,
>                            space_names[ssw & DFC], fp->ptregs.pc);
>                     goto buserr;
>             }
>             /* Don't try to do anything further if an exception was
>                handled. */
>             if (do_page_fault (&fp->ptregs, addr, errorcode) < 0)
>                     return;
>
> But we never get to do_page_fault(), as ssw = 5 (SUPER_DATA).
>
> The "if (ssw & 4) { ... }" chunk was added in commit
> e48d483d581278fae02a5fffeba2b1fef47be4d4 (from full-history-linux):

I guess it just reinstates the condition in the first hunk.

-       if (fp->ptregs.sr & PS_S) {
-               /* kernel fault must be a data fault to user space */

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Boot crash on 68030, was Re: [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes

[Mikael Pettersson]

Finn Thain writes:
 > 
 > On Tue, 10 Dec 2013, Andreas Schwab wrote:
 > 
 > > Finn Thain <fthain@telegraphics.com.au> writes:
 > > 
 > > > Data read fault at 0x00000000 in Super Data (pc=0x3afec)
 > > > BAD KERNEL BUSERR
 > > > Oops: 00000000
 > > > Modules linked in:
 > > > PC: [<0003afec>] cmpxchg_futex_value_locked+0x14/0x4a
 > > 
 > > What does it do here?
 > 
 > What happens next is that swapper dies leading to panic (see below).
 > 
 > It appears that the call graph looks like this,
 > 
 > futex_init()
 >   cmpxchg_futex_value_locked(&curval, NULL, 0, 0)
 >     pagefault_disable();
 >     futex_atomic_cmpxchg_inatomic(curval, NULL, 0, 0)
 >       get_user(val, NULL)
 > 
 > That is, futex_init() passes a NULL pointer expecting it to fault, as 
 > described in the comments in kernel/futex.c. Clearly the fault is not 
 > expected to be fatal.
 > 
 > Finn

Since it works for 040 I'd have to suspect some breakage in the
pagefault handling for 030.  However I haven't looked at that code
in any detail yet.

/Mikael

 > 
 > 
 > MacLinux
 > 
 >  vidaddr: 60040000
 >   _stext: 00001000
 > bootinfo: 002CC000
 >    cpuid: 00000000
 >  sccbase: 50F04000
 > 
 > ABCFGHIJK
 > Linux version 3.10.0-rc2-mac-111606-ge4f2dfb (fthain@nippy) (gcc version 
 > 4.4.6 (GCC) ) #14 Tue Dec 10 11:31:21 EST 2013
 > bootconsole [early0] enabled
 > Detected Macintosh model: 33
 > VIA1 at 50f00000 is a 6522 or clone
 > VIA2 at 50f02000 is a 6522 or clone
 > Apple Macintosh PowerBook 180
 > Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 3045
 > Kernel command line: console=ttyS0
 > PID hash table entries: 64 (order: -4, 256 bytes)
 > Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
 > Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
 > Sorting __ex_table...
 > Memory: 9252k/9252k available (1948k kernel code, 984k data, 104k init)
 > Virtual kernel memory layout:
 >     vector  : 0x0029318c - 0x0029358c   (   1 KiB)
 >     kmap    : 0xd0000000 - 0xf0000000   ( 512 MiB)
 >     vmalloc : 0x01000000 - 0xd0000000   (3312 MiB)
 >     lowmem  : 0x00000000 - 0x00c00000   (  12 MiB)
 >       .init : 0x002b2000 - 0x002cc000   ( 104 KiB)
 >       .text : 0x00001000 - 0x001e71aa   (1945 KiB)
 >       .data : 0x001e9d60 - 0x002b11d0   ( 798 KiB)
 >       .bss  : 0x00292f80 - 0x002b11d0   ( 121 KiB)
 > SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
 > NR_IRQS:72
 > Killing onboard sonic... Done.
 > WARNING: Persistent clock returned invalid value!
 >          Check your CMOS/BIOS settings.
 > Console: colour dummy device 80x25
 > console [ttyS0] enabled, bootconsole disabled
 > console [ttyS0] enabled, bootconsole disabled
 > Calibrating delay loop... 7.83 BogoMIPS (lpj=39168)
 > pid_max: default: 32768 minimum: 301
 > Mount-cache hash table entries: 512
 > devtmpfs: initialized
 > NET: Registered protocol family 16
 > bio: create slab <bio-0> at 0
 > NuBus: Scanning NuBus slots.
 > SCSI subsystem initialized
 > NET: Registered protocol family 2
 > TCP established hash table entries: 512 (order: 0, 4096 bytes)
 > TCP bind hash table entries: 512 (order: -1, 2048 bytes)
 > TCP: Hash tables configured (established 512 bind 512)
 > TCP: reno registered
 > UDP hash table entries: 256 (order: 0, 4096 bytes)
 > UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
 > NET: Registered protocol family 1
 > RPC: Registered named UNIX socket transport module.
 > RPC: Registered udp transport module.
 > RPC: Registered tcp transport module.
 > RPC: Registered tcp NFSv4.1 backchannel transport module.
 > Data read fault at 0x00000000 in Super Data (pc=0x3afec)
 > BAD KERNEL BUSERR
 > Oops: 00000000
 > Modules linked in:
 > PC: [<0003afec>] cmpxchg_futex_value_locked+0x14/0x4a
 > SR: 2004  SP: 0082fed4  a2: 0082c000
 > d0: 00000000    d1: 00000001    d2: 00000018    d3: 00000000
 > d4: 00000061    d5: 00001000    a0: 00000000    a1: 0082e000
 > Process swapper (pid: 1, task=0082c000)
 > Frame format=B ssw=074d isc=4a80 isb=661c daddr=00000000 dobuf=00000001
 > baddr=0003aff2 dibuf=00000000 ver=f
 > Stack from 0082ff5c:
 >         002b8cb8 0082ff70 00000000 00000000 00000000 00000000 00000000 000020ac
 >         00000018 00000007 00000061 00001000 00000000 00000000 002cab50 00002008
 >         002b3a56 002b8ca4 0082c3f0 00000000 0082c53c 001e316a 00000000 00000000
 >         001e3172 001e316a 000025d4 00000000 00000000 00000000 00000000 00000000
 >         00000000 00000000 00000000 00000000 00000000 00000000 00000000 20000000
 >         00000000
 > Call Trace: [<002b8cb8>] futex_init+0x14/0x54
 >  [<000020ac>] do_one_initcall+0xa4/0x144
 >  [<00001000>] kernel_pg_dir+0x0/0x1000
 >  [<00002008>] do_one_initcall+0x0/0x144
 >  [<002b3a56>] kernel_init_freeable+0xca/0x152
 >  [<002b8ca4>] futex_init+0x0/0x54
 >  [<001e316a>] kernel_init+0x0/0xc8
 >  [<001e3172>] kernel_init+0x8/0xc8
 >  [<001e316a>] kernel_init+0x0/0xc8
 >  [<000025d4>] ret_from_kernel_thread+0xc/0x14
 > 
 > Code: 200f 0280 ffff e000 2240 52a9 0010 4280 <0e90> 1000 4a80 661c b2af 
 > 000c 660c 226f 0010 0e90 9800 4a80 660a 206f 0004 2081
 > Disabling lock debugging due to kernel taint
 > note: swapper[1] exited with preempt_count 1
 > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

--