Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-10-04 Thread Geert Uytterhoeven 
On Thu, 4 Oct 2007, Mikael Pettersson wrote:
> On Wed, 3 Oct 2007 22:33:46 +0300, Riku Voipio wrote:
> > What's the state of this patch? I can confirm tst-robust1
> > from glibc testsuite locks a armv5 machine hard. With this patch
> > applied, the test succeeds.
> 
> There were no comments from any Linux arch or futex maintainer.

Probably because it wasn't posted to linux-arch?

> Because of that I intend to submit an ARM-only patch when 2.6.23
> has been released.
> 
> /Mikael
> 
> > > The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
> > > asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
> > > avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
> > > v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
> > > horribly broken on them. There have also been reports recently that PI
> > > futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
> > > just being an -ENOSYS stub.
> > 
> > This an effective local DOS bug on the affected architectures, too.. 
> > 
> > > The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
> > > terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
> > > It obviously doesn't support SMP, but UP-only support should go a long
> > > way for users of the affected archs.
> > > 
> > > I'm using this patch now and it has allowed me to build and use glibc-2.4
> > > with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
> > > (Finally I can ditch LinuxThreads :->)
> > > 
> > > Comments?
> > > 
> > > /Mikael
> > > 
> > > --- linux-2.6.22/include/asm-generic/futex.h.~1~  2007-02-04 
> > > 19:44:54.0 +0100
> > > +++ linux-2.6.22/include/asm-generic/futex.h  2007-08-01 
> > > 19:03:43.0 +0200
> > > @@ -4,6 +4,7 @@
> > >  #ifdef __KERNEL__
> > >  
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  
> > > @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
> > >  static inline int
> > >  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
> > > {
> > > +#ifdef CONFIG_SMP
> > >   return -ENOSYS;
> > > +#else
> > > + int curval, ret;
> > > +
> > > + if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
> > > + return -EFAULT;
> > > +
> > > + preempt_disable();
> > > +
> > > + ret = -EFAULT;
> > > + if (__copy_from_user_inatomic(, uaddr, sizeof(int)))
> > > + goto out;
> > > +
> > > + ret = curval;
> > > + if (curval != oldval)
> > > + goto out;
> > > +
> > > + ret = -EFAULT;
> > > + if (__copy_to_user_inatomic(uaddr, , sizeof(int)))
> > > + goto out;
> > > +
> > > + ret = newval;
> > > +
> > > + out:
> > > + preempt_enable();
> > > + return ret;
> > > +#endif
> > >  }
> > >  
> > >  #endif
> > > -
> > 
> > - -- 
> > "rm -rf" only sounds scary if you don't have backups
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.6 (GNU/Linux)
> > 
> > iD8DBQFHA+6aibPvMsrqrwMRAlMuAKCBf7qpD2dETgU+RgnDG4ArVvFp3gCgrewq
> > 4KvOt40U1MAPM7g4F/Ps5jk=
> > =68gr
> > -END PGP SIGNATURE-
> > 
> -
> 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/
> 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

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
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-10-04 Thread Mikael Pettersson 
On Wed, 3 Oct 2007 22:33:46 +0300, Riku Voipio wrote:
> What's the state of this patch? I can confirm tst-robust1
> from glibc testsuite locks a armv5 machine hard. With this patch
> applied, the test succeeds.

There were no comments from any Linux arch or futex maintainer.
Because of that I intend to submit an ARM-only patch when 2.6.23
has been released.

/Mikael

> > The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
> > asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
> > avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
> > v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
> > horribly broken on them. There have also been reports recently that PI
> > futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
> > just being an -ENOSYS stub.
> 
> This an effective local DOS bug on the affected architectures, too.. 
> 
> > The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
> > terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
> > It obviously doesn't support SMP, but UP-only support should go a long
> > way for users of the affected archs.
> > 
> > I'm using this patch now and it has allowed me to build and use glibc-2.4
> > with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
> > (Finally I can ditch LinuxThreads :->)
> > 
> > Comments?
> > 
> > /Mikael
> > 
> > --- linux-2.6.22/include/asm-generic/futex.h.~1~2007-02-04 
> > 19:44:54.0 +0100
> > +++ linux-2.6.22/include/asm-generic/futex.h2007-08-01 
> > 19:03:43.0 +0200
> > @@ -4,6 +4,7 @@
> >  #ifdef __KERNEL__
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
> >  static inline int
> >  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
> > {
> > +#ifdef CONFIG_SMP
> > return -ENOSYS;
> > +#else
> > +   int curval, ret;
> > +
> > +   if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
> > +   return -EFAULT;
> > +
> > +   preempt_disable();
> > +
> > +   ret = -EFAULT;
> > +   if (__copy_from_user_inatomic(, uaddr, sizeof(int)))
> > +   goto out;
> > +
> > +   ret = curval;
> > +   if (curval != oldval)
> > +   goto out;
> > +
> > +   ret = -EFAULT;
> > +   if (__copy_to_user_inatomic(uaddr, , sizeof(int)))
> > +   goto out;
> > +
> > +   ret = newval;
> > +
> > + out:
> > +   preempt_enable();
> > +   return ret;
> > +#endif
> >  }
> >  
> >  #endif
> > -
> 
> - -- 
> "rm -rf" only sounds scary if you don't have backups
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFHA+6aibPvMsrqrwMRAlMuAKCBf7qpD2dETgU+RgnDG4ArVvFp3gCgrewq
> 4KvOt40U1MAPM7g4F/Ps5jk=
> =68gr
> -END PGP SIGNATURE-
> 
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-10-04 Thread Mikael Pettersson 
On Wed, 3 Oct 2007 22:33:46 +0300, Riku Voipio wrote:
 What's the state of this patch? I can confirm tst-robust1
 from glibc testsuite locks a armv5 machine hard. With this patch
 applied, the test succeeds.

There were no comments from any Linux arch or futex maintainer.
Because of that I intend to submit an ARM-only patch when 2.6.23
has been released.

/Mikael

  The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
  asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
  avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
  v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
  horribly broken on them. There have also been reports recently that PI
  futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
  just being an -ENOSYS stub.
 
 This an effective local DOS bug on the affected architectures, too.. 
 
  The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
  terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
  It obviously doesn't support SMP, but UP-only support should go a long
  way for users of the affected archs.
  
  I'm using this patch now and it has allowed me to build and use glibc-2.4
  with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
  (Finally I can ditch LinuxThreads :-)
  
  Comments?
  
  /Mikael
  
  --- linux-2.6.22/include/asm-generic/futex.h.~1~2007-02-04 
  19:44:54.0 +0100
  +++ linux-2.6.22/include/asm-generic/futex.h2007-08-01 
  19:03:43.0 +0200
  @@ -4,6 +4,7 @@
   #ifdef __KERNEL__
   
   #include linux/futex.h
  +#include linux/preempt.h
   #include asm/errno.h
   #include asm/uaccess.h
   
  @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
   static inline int
   futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
  {
  +#ifdef CONFIG_SMP
  return -ENOSYS;
  +#else
  +   int curval, ret;
  +
  +   if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
  +   return -EFAULT;
  +
  +   preempt_disable();
  +
  +   ret = -EFAULT;
  +   if (__copy_from_user_inatomic(curval, uaddr, sizeof(int)))
  +   goto out;
  +
  +   ret = curval;
  +   if (curval != oldval)
  +   goto out;
  +
  +   ret = -EFAULT;
  +   if (__copy_to_user_inatomic(uaddr, newval, sizeof(int)))
  +   goto out;
  +
  +   ret = newval;
  +
  + out:
  +   preempt_enable();
  +   return ret;
  +#endif
   }
   
   #endif
  -
 
 - -- 
 rm -rf only sounds scary if you don't have backups
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (GNU/Linux)
 
 iD8DBQFHA+6aibPvMsrqrwMRAlMuAKCBf7qpD2dETgU+RgnDG4ArVvFp3gCgrewq
 4KvOt40U1MAPM7g4F/Ps5jk=
 =68gr
 -END PGP SIGNATURE-
 
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-10-04 Thread Geert Uytterhoeven 
On Thu, 4 Oct 2007, Mikael Pettersson wrote:
 On Wed, 3 Oct 2007 22:33:46 +0300, Riku Voipio wrote:
  What's the state of this patch? I can confirm tst-robust1
  from glibc testsuite locks a armv5 machine hard. With this patch
  applied, the test succeeds.
 
 There were no comments from any Linux arch or futex maintainer.

Probably because it wasn't posted to linux-arch?

 Because of that I intend to submit an ARM-only patch when 2.6.23
 has been released.
 
 /Mikael
 
   The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
   asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
   avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
   v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
   horribly broken on them. There have also been reports recently that PI
   futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
   just being an -ENOSYS stub.
  
  This an effective local DOS bug on the affected architectures, too.. 
  
   The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
   terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
   It obviously doesn't support SMP, but UP-only support should go a long
   way for users of the affected archs.
   
   I'm using this patch now and it has allowed me to build and use glibc-2.4
   with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
   (Finally I can ditch LinuxThreads :-)
   
   Comments?
   
   /Mikael
   
   --- linux-2.6.22/include/asm-generic/futex.h.~1~  2007-02-04 
   19:44:54.0 +0100
   +++ linux-2.6.22/include/asm-generic/futex.h  2007-08-01 
   19:03:43.0 +0200
   @@ -4,6 +4,7 @@
#ifdef __KERNEL__

#include linux/futex.h
   +#include linux/preempt.h
#include asm/errno.h
#include asm/uaccess.h

   @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
   {
   +#ifdef CONFIG_SMP
 return -ENOSYS;
   +#else
   + int curval, ret;
   +
   + if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
   + return -EFAULT;
   +
   + preempt_disable();
   +
   + ret = -EFAULT;
   + if (__copy_from_user_inatomic(curval, uaddr, sizeof(int)))
   + goto out;
   +
   + ret = curval;
   + if (curval != oldval)
   + goto out;
   +
   + ret = -EFAULT;
   + if (__copy_to_user_inatomic(uaddr, newval, sizeof(int)))
   + goto out;
   +
   + ret = newval;
   +
   + out:
   + preempt_enable();
   + return ret;
   +#endif
}

#endif
   -
  
  - -- 
  rm -rf only sounds scary if you don't have backups
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.6 (GNU/Linux)
  
  iD8DBQFHA+6aibPvMsrqrwMRAlMuAKCBf7qpD2dETgU+RgnDG4ArVvFp3gCgrewq
  4KvOt40U1MAPM7g4F/Ps5jk=
  =68gr
  -END PGP SIGNATURE-
  
 -
 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/
 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

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
-
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/

[PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-10-03 Thread Riku Voipio 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What's the state of this patch? I can confirm tst-robust1
from glibc testsuite locks a armv5 machine hard. With this patch
applied, the test succeeds.

> The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
> asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
> avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
> v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
> horribly broken on them. There have also been reports recently that PI
> futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
> just being an -ENOSYS stub.

This an effective local DOS bug on the affected architectures, too.. 

> The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
> terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
> It obviously doesn't support SMP, but UP-only support should go a long
> way for users of the affected archs.
> 
> I'm using this patch now and it has allowed me to build and use glibc-2.4
> with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
> (Finally I can ditch LinuxThreads :->)
> 
> Comments?
> 
> /Mikael
> 
> --- linux-2.6.22/include/asm-generic/futex.h.~1~  2007-02-04 
> 19:44:54.0 +0100
> +++ linux-2.6.22/include/asm-generic/futex.h  2007-08-01 19:03:43.0 
> +0200
> @@ -4,6 +4,7 @@
>  #ifdef __KERNEL__
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
>  static inline int
>  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
> {
> +#ifdef CONFIG_SMP
>   return -ENOSYS;
> +#else
> + int curval, ret;
> +
> + if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
> + return -EFAULT;
> +
> + preempt_disable();
> +
> + ret = -EFAULT;
> + if (__copy_from_user_inatomic(, uaddr, sizeof(int)))
> + goto out;
> +
> + ret = curval;
> + if (curval != oldval)
> + goto out;
> +
> + ret = -EFAULT;
> + if (__copy_to_user_inatomic(uaddr, , sizeof(int)))
> + goto out;
> +
> + ret = newval;
> +
> + out:
> + preempt_enable();
> + return ret;
> +#endif
>  }
>  
>  #endif
> -

- -- 
"rm -rf" only sounds scary if you don't have backups
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHA+6aibPvMsrqrwMRAlMuAKCBf7qpD2dETgU+RgnDG4ArVvFp3gCgrewq
4KvOt40U1MAPM7g4F/Ps5jk=
=68gr
-END PGP SIGNATURE-
-
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/

[PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-10-03 Thread Riku Voipio 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What's the state of this patch? I can confirm tst-robust1
from glibc testsuite locks a armv5 machine hard. With this patch
applied, the test succeeds.

 The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
 asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
 avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
 v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
 horribly broken on them. There have also been reports recently that PI
 futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
 just being an -ENOSYS stub.

This an effective local DOS bug on the affected architectures, too.. 

 The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
 terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
 It obviously doesn't support SMP, but UP-only support should go a long
 way for users of the affected archs.
 
 I'm using this patch now and it has allowed me to build and use glibc-2.4
 with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
 (Finally I can ditch LinuxThreads :-)
 
 Comments?
 
 /Mikael
 
 --- linux-2.6.22/include/asm-generic/futex.h.~1~  2007-02-04 
 19:44:54.0 +0100
 +++ linux-2.6.22/include/asm-generic/futex.h  2007-08-01 19:03:43.0 
 +0200
 @@ -4,6 +4,7 @@
  #ifdef __KERNEL__
  
  #include linux/futex.h
 +#include linux/preempt.h
  #include asm/errno.h
  #include asm/uaccess.h
  
 @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
  static inline int
  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
 {
 +#ifdef CONFIG_SMP
   return -ENOSYS;
 +#else
 + int curval, ret;
 +
 + if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
 + return -EFAULT;
 +
 + preempt_disable();
 +
 + ret = -EFAULT;
 + if (__copy_from_user_inatomic(curval, uaddr, sizeof(int)))
 + goto out;
 +
 + ret = curval;
 + if (curval != oldval)
 + goto out;
 +
 + ret = -EFAULT;
 + if (__copy_to_user_inatomic(uaddr, newval, sizeof(int)))
 + goto out;
 +
 + ret = newval;
 +
 + out:
 + preempt_enable();
 + return ret;
 +#endif
  }
  
  #endif
 -

- -- 
rm -rf only sounds scary if you don't have backups
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHA+6aibPvMsrqrwMRAlMuAKCBf7qpD2dETgU+RgnDG4ArVvFp3gCgrewq
4KvOt40U1MAPM7g4F/Ps5jk=
=68gr
-END PGP SIGNATURE-
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Lennert Buytenhek 
On Thu, Aug 02, 2007 at 02:06:27AM +0200, Mikael Pettersson wrote:

> > > @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
> > >  static inline int
> > >  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
> > >  {
> > > +#ifdef CONFIG_SMP
> > >   return -ENOSYS;
> > > +#else
> > 
> > Since the callers of futex_atomic_cmpxchg_inatomic() don't really
> > seem prepared to deal with -ENOSYS (e.g. the handle_futex_death()
> > infinite loop when it gets -ENOSYS), it seems better never to
> > return -ENOSYS from this function at all.
> > 
> > What if you just stick an #error in here in the SMP case?
> 
> The problem with #error is that it would cause compile-time
> regressions. I assume that e.g. alpha supports building SMP
> kernels, but #error would prevent that.
> 
> Thus I opted to fix the UP case while leaving the SMP case
> unchanged. Actually I think the SMP case should be a BUG()
> rather than -ENOSYS,

Probably.  Or handle -ENOSYS in the callers -- but that's more
work, and would cease to be necessary once everyone implements
futex_atomic_cmpxchg_inatomic().


> but that's a different issue from the UP case which I really do
> want to see fixed.

ACK.
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Mikael Pettersson 
On Thu, 2 Aug 2007 01:49:02 +0200, Lennert Buytenhek wrote:
> On Thu, Aug 02, 2007 at 01:00:21AM +0200, Mikael Pettersson wrote:
> 
> > @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
> >  static inline int
> >  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
> >  {
> > +#ifdef CONFIG_SMP
> > return -ENOSYS;
> > +#else
> 
> Since the callers of futex_atomic_cmpxchg_inatomic() don't really
> seem prepared to deal with -ENOSYS (e.g. the handle_futex_death()
> infinite loop when it gets -ENOSYS), it seems better never to
> return -ENOSYS from this function at all.
> 
> What if you just stick an #error in here in the SMP case?

The problem with #error is that it would cause compile-time
regressions. I assume that e.g. alpha supports building SMP
kernels, but #error would prevent that.

Thus I opted to fix the UP case while leaving the SMP case
unchanged. Actually I think the SMP case should be a BUG()
rather than -ENOSYS, but that's a different issue from the
UP case which I really do want to see fixed.

/Mikael
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Lennert Buytenhek 
On Thu, Aug 02, 2007 at 01:00:21AM +0200, Mikael Pettersson wrote:

> @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
>  static inline int
>  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
>  {
> +#ifdef CONFIG_SMP
>   return -ENOSYS;
> +#else

Since the callers of futex_atomic_cmpxchg_inatomic() don't really
seem prepared to deal with -ENOSYS (e.g. the handle_futex_death()
infinite loop when it gets -ENOSYS), it seems better never to
return -ENOSYS from this function at all.

What if you just stick an #error in here in the SMP case?
-
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/

[PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Mikael Pettersson 
[Resend. I messed up the To: line the first time]

As has been reported recently by Lennert Buytenhek, robust futexes
are broken on ARM:

>If you're also running into glibc's tst-robust1 test suite test
>locking up your ARM machine, you're probably running into the fact
>that asm-arm/futex.h includes asm-generic/futex.h, and
>asm-generic/futex.h defines futex_atomic_cmpxchg_inatomic() to
>return -ENOSYS.  This causes handle_futex_death() to loop forever.

I can confirm this statement: building glibc-2.4 with NPTL on
ARM hangs the kernel when the test suite reaches tst-robust1.

The problem is that kernel/futex.c expects futex_atomic_cmpxchg_inatomic()
to return -EFAULT or the new value. It doesn't expect -ENOSYS at all, and
generally -ENOSYS causes the futex code to loop, hanging the kernel.

The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
horribly broken on them. There have also been reports recently that PI
futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
just being an -ENOSYS stub.

The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
It obviously doesn't support SMP, but UP-only support should go a long
way for users of the affected archs.

I'm using this patch now and it has allowed me to build and use glibc-2.4
with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
(Finally I can ditch LinuxThreads :->)

Comments?

/Mikael

--- linux-2.6.22/include/asm-generic/futex.h.~1~2007-02-04 
19:44:54.0 +0100
+++ linux-2.6.22/include/asm-generic/futex.h2007-08-01 19:03:43.0 
+0200
@@ -4,6 +4,7 @@
 #ifdef __KERNEL__
 
 #include 
+#include 
 #include 
 #include 
 
@@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
 static inline int
 futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
 {
+#ifdef CONFIG_SMP
return -ENOSYS;
+#else
+   int curval, ret;
+
+   if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
+   return -EFAULT;
+
+   preempt_disable();
+
+   ret = -EFAULT;
+   if (__copy_from_user_inatomic(, uaddr, sizeof(int)))
+   goto out;
+
+   ret = curval;
+   if (curval != oldval)
+   goto out;
+
+   ret = -EFAULT;
+   if (__copy_to_user_inatomic(uaddr, , sizeof(int)))
+   goto out;
+
+   ret = newval;
+
+ out:
+   preempt_enable();
+   return ret;
+#endif
 }
 
 #endif
-
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/

[PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Mikael Pettersson 
[Resend. I messed up the To: line the first time]

As has been reported recently by Lennert Buytenhek, robust futexes
are broken on ARM:

If you're also running into glibc's tst-robust1 test suite test
locking up your ARM machine, you're probably running into the fact
that asm-arm/futex.h includes asm-generic/futex.h, and
asm-generic/futex.h defines futex_atomic_cmpxchg_inatomic() to
return -ENOSYS.  This causes handle_futex_death() to loop forever.

I can confirm this statement: building glibc-2.4 with NPTL on
ARM hangs the kernel when the test suite reaches tst-robust1.

The problem is that kernel/futex.c expects futex_atomic_cmpxchg_inatomic()
to return -EFAULT or the new value. It doesn't expect -ENOSYS at all, and
generally -ENOSYS causes the futex code to loop, hanging the kernel.

The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
asm/futex.h implementations, but a number of archs (alpha, arm, arm26,
avr32, blackfin, cris, h8300, m32r, m68k, mk68knommu, sh64, sparc, um,
v850, and xtensa) use asm-generic/futex.h, which makes robust futexes
horribly broken on them. There have also been reports recently that PI
futexes are broken due to the generic futex_atomic_cmpxchg_inatomic()
just being an -ENOSYS stub.

The patch below implements the generic futex_atomic_cmpxchg_inatomic() in
terms of __copy_{from,to}_user_inatomic() and preempt_{disable,enable}().
It obviously doesn't support SMP, but UP-only support should go a long
way for users of the affected archs.

I'm using this patch now and it has allowed me to build and use glibc-2.4
with NPTL on ARM (glibc-2.4-11.src.rpm from FC5 + ARM fixes).
(Finally I can ditch LinuxThreads :-)

Comments?

/Mikael

--- linux-2.6.22/include/asm-generic/futex.h.~1~2007-02-04 
19:44:54.0 +0100
+++ linux-2.6.22/include/asm-generic/futex.h2007-08-01 19:03:43.0 
+0200
@@ -4,6 +4,7 @@
 #ifdef __KERNEL__
 
 #include linux/futex.h
+#include linux/preempt.h
 #include asm/errno.h
 #include asm/uaccess.h
 
@@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
 static inline int
 futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
 {
+#ifdef CONFIG_SMP
return -ENOSYS;
+#else
+   int curval, ret;
+
+   if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
+   return -EFAULT;
+
+   preempt_disable();
+
+   ret = -EFAULT;
+   if (__copy_from_user_inatomic(curval, uaddr, sizeof(int)))
+   goto out;
+
+   ret = curval;
+   if (curval != oldval)
+   goto out;
+
+   ret = -EFAULT;
+   if (__copy_to_user_inatomic(uaddr, newval, sizeof(int)))
+   goto out;
+
+   ret = newval;
+
+ out:
+   preempt_enable();
+   return ret;
+#endif
 }
 
 #endif
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Lennert Buytenhek 
On Thu, Aug 02, 2007 at 01:00:21AM +0200, Mikael Pettersson wrote:

 @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
  static inline int
  futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
  {
 +#ifdef CONFIG_SMP
   return -ENOSYS;
 +#else

Since the callers of futex_atomic_cmpxchg_inatomic() don't really
seem prepared to deal with -ENOSYS (e.g. the handle_futex_death()
infinite loop when it gets -ENOSYS), it seems better never to
return -ENOSYS from this function at all.

What if you just stick an #error in here in the SMP case?
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Mikael Pettersson 
On Thu, 2 Aug 2007 01:49:02 +0200, Lennert Buytenhek wrote:
 On Thu, Aug 02, 2007 at 01:00:21AM +0200, Mikael Pettersson wrote:
 
  @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
   static inline int
   futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
   {
  +#ifdef CONFIG_SMP
  return -ENOSYS;
  +#else
 
 Since the callers of futex_atomic_cmpxchg_inatomic() don't really
 seem prepared to deal with -ENOSYS (e.g. the handle_futex_death()
 infinite loop when it gets -ENOSYS), it seems better never to
 return -ENOSYS from this function at all.
 
 What if you just stick an #error in here in the SMP case?

The problem with #error is that it would cause compile-time
regressions. I assume that e.g. alpha supports building SMP
kernels, but #error would prevent that.

Thus I opted to fix the UP case while leaving the SMP case
unchanged. Actually I think the SMP case should be a BUG()
rather than -ENOSYS, but that's a different issue from the
UP case which I really do want to see fixed.

/Mikael
-
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/

Re: [PATCH][RFC] unbreak generic futex_atomic_cmpxchg_inatomic() on UP

2007-08-01 Thread Lennert Buytenhek 
On Thu, Aug 02, 2007 at 02:06:27AM +0200, Mikael Pettersson wrote:

   @@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op, 
static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
{
   +#ifdef CONFIG_SMP
 return -ENOSYS;
   +#else
  
  Since the callers of futex_atomic_cmpxchg_inatomic() don't really
  seem prepared to deal with -ENOSYS (e.g. the handle_futex_death()
  infinite loop when it gets -ENOSYS), it seems better never to
  return -ENOSYS from this function at all.
  
  What if you just stick an #error in here in the SMP case?
 
 The problem with #error is that it would cause compile-time
 regressions. I assume that e.g. alpha supports building SMP
 kernels, but #error would prevent that.
 
 Thus I opted to fix the UP case while leaving the SMP case
 unchanged. Actually I think the SMP case should be a BUG()
 rather than -ENOSYS,

Probably.  Or handle -ENOSYS in the callers -- but that's more
work, and would cease to be necessary once everyone implements
futex_atomic_cmpxchg_inatomic().


 but that's a different issue from the UP case which I really do
 want to see fixed.

ACK.
-
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/