diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2012-12-23 20:56:40 +0100 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2012-12-26 07:15:02 +0100 |
commit | 8d9807b109497ca41d363dc7b6ff2bb6c0d52524 (patch) | |
tree | 3f6768b1ab6ee104c7e41253474e358291bc0537 /crypto/tgr192.c | |
parent | switch compat_sys_sigaltstack() to COMPAT_SYSCALL_DEFINE (diff) | |
download | linux-8d9807b109497ca41d363dc7b6ff2bb6c0d52524.tar.xz linux-8d9807b109497ca41d363dc7b6ff2bb6c0d52524.zip |
switch compat_sys_wait4() and compat_sys_waitid() to COMPAT_SYSCALL_DEFINE
Strictly speaking, ppc64 needs it for C ABI compliance. Realistically
I would be very surprised if e.g. passing 0xffffffff as 'options'
argument to waitid() from 32bit task would cause problems, but yes,
it puts us into undefined behaviour territory. ppc64 expects int
argument to be passed in 64bit register with bits 31..63 containing
the same value. SYSCALL_DEFINE on ppc provides a wrapper that normalizes
the value passed from userland; so does COMPAT_SYSCALL_DEFINE. Plain
declaration of compat_sys_something() with an int argument obviously
doesn't. Again, for wait4 and waitid I would be extremely surprised
if gcc started to produce code depending on that value having been
properly sign-extended - the argument(s) in question end up passed
blindly to sys_wait4 and sys_waitid resp. and normalization for native
syscalls takes care of their use there. Still, better to use
COMPAT_SYSCALL_DEFINE here than worry about nasal daemons...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'crypto/tgr192.c')
0 files changed, 0 insertions, 0 deletions