Messages in this thread | | | Date | Sat, 29 May 2004 12:23:19 -0700 | From | "David S. Miller" <> | Subject | compat syscall args |
| |
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |