Re: [PATCH] Pass nr_wake2 to futex_wake_op

[Andrew Morton]

On Tue, 17 Jul 2007 13:31:29 +0200
Andreas Schwab <schwab@xxxxxxx> 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 <schwab@xxxxxxx>
> 
> ---
>  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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/