parisc: fix fanotify_mark() syscall on 32bit compat kernel
authorHelge Deller <deller@gmx.de>
Thu, 10 Jul 2014 16:07:17 +0000 (18:07 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 17 Jul 2014 23:21:02 +0000 (16:21 -0700)
commit822c60a5f4eb9c84ece4bb4738335ec029733d44
tree46bb8cd607d7aa39275d65c7fb98ea5e12525172
parent207127a53d187d1a321a0ebca3baaa5fffd54d80
parisc: fix fanotify_mark() syscall on 32bit compat kernel

commit ab8a261ba5e2dd9206da640de5870cc31d568a7c upstream.

On parisc we can not use the existing compat implementation for fanotify_mark()
because for the 64bit mask parameter the higher and lower 32bits are ordered
differently than what the compat function expects from big endian
architectures.

Specifically:
It finally turned out, that on hppa we end up with different assignments
of parameters to kernel arguments depending on if we call the glibc
wrapper function
 int fanotify_mark (int __fanotify_fd, unsigned int __flags,
                    uint64_t __mask, int __dfd, const char *__pathname);
or directly calling the syscall manually
 syscall(__NR_fanotify_mark, ...)

Reason is, that the syscall() function is implemented as C-function and
because we now have the sysno as first parameter in front of the other
parameters the compiler will unexpectedly add an empty paramenter in
front of the u64 value to ensure the correct calling alignment for 64bit
values.
This means, on hppa you can't simply use syscall() to call the kernel
fanotify_mark() function directly, but you have to use the glibc
function instead.

This patch fixes the kernel in the hppa-arch specifc coding to adjust
the parameters in a way as if userspace calls the glibc wrapper function
fanotify_mark().

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/parisc/kernel/sys_parisc32.c
arch/parisc/kernel/syscall_table.S