summaryrefslogtreecommitdiffstats
path: root/crypto/tgr192.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2012-12-23 20:56:40 +0100
committerAl Viro <viro@zeniv.linux.org.uk>2012-12-26 07:15:02 +0100
commit8d9807b109497ca41d363dc7b6ff2bb6c0d52524 (patch)
tree3f6768b1ab6ee104c7e41253474e358291bc0537 /crypto/tgr192.c
parentswitch compat_sys_sigaltstack() to COMPAT_SYSCALL_DEFINE (diff)
downloadlinux-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