compat syscall args

["David S. Miller" <davem@redhat.com>]

Arnd asked:

> If sparc64 has this problem only for the fifth syscall argument, 
> does that mean that e.g. compat_sys_futex and 
> compat_sys_mq_timed{send,receive} have the same bug? If this is
> a more general, i.e. not limited to the last argument, there is a
> potential problem in lots of syscalls.

Here is the issue.  In the sparc64 C calling conventions, it is
assumed that 32-bit signed values are sign extended by the
caller.

This means that, at syscall invocation time, we have to choose
between either:

1) sign extending all syscall args for the C code, then explicitly
   zero-extending all non-signed syscall args.  This would require
   the most amount of compat layer code help.

2) zero extending all syscall args for the C code, then expliticly
   sign-extending all signed syscall args.

3) some mixture of 1 and 2

#3 is what sparc64 does, it hits the highest number of system
call arguments correctly.  Specifically we:

arg0: zero-extend
arg1: zero-extend
arg2: zero-extend
arg3: zero-extend
arg4: leave as-is
arg5: leave as-is

I remember discussing this with Andi Kleen before.

Each platform is going to behave differently in this area, so
I suppose the right thing to do really is to have the arch
specific code use little zero/sign extender stubs when necessary
so that the compat layer can assume that the args are properly
sign/zero extended already.  I guess this is how I'll fix this
up on sparc64 for now.

Comments?