On Tue, 17 Jul 2007 13:31:29 +0200 Andreas Schwab <[EMAIL PROTECTED]> wrote:
> The fourth argument of sys_futex is ignored when op == FUTEX_WAKE_OP, > but futex_wake_op expects it as its nr_wake2 parameter. > > The only user of this operation in glibc is always passing 1, so this > bug had no consequences so far. > > Signed-off-by: Andreas Schwab <[EMAIL PROTECTED]> > > --- > kernel/futex.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > --- linux-2.6.22.orig/kernel/futex.c 2007-07-02 00:40:44.000000000 +0200 > +++ linux-2.6.22/kernel/futex.c 2007-07-07 15:56:42.000000000 +0200 > @@ -2061,8 +2061,10 @@ asmlinkage long sys_futex(u32 __user *ua > } > /* > * requeue parameter in 'utime' if cmd == FUTEX_REQUEUE. > + * number of waiters to wake in 'utime' if cmd == FUTEX_WAKE_OP. > */ > - if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE) > + if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE || > + cmd == FUTEX_WAKE_OP) > val2 = (u32) (unsigned long) utime; > > return do_futex(uaddr, op, val, tp, uaddr2, val2, val3); > So if an application or glibc _does_ start passing in non-1 values, it will malfunction on earlier kernels? So that userspace code would need to have a test for the kernel version, I assume? All a bit of a hassle. Still, I'd propose that this change (if the thus-far-silent cc'ees agree with it?) go into 2.6.22.x at least. If it gets accepted into 2.6.22.x then applications (or glibc) will need to test for kernels as far back as 2.6.22. Really they would need to test for the correct value of x in 2.6.22.x, but I don't know if glibc is set up for that. Thoughts? - 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/