| Message ID | 20240624163707.299494-7-arnd@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | linux system call fixes | expand |
On Mon, Jun 24, 2024 at 06:37:04PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The sys_fanotify_mark() syscall on parisc uses the reverse word order > for the two halves of the 64-bit argument compared to all syscalls on > all 32-bit architectures. As far as I can tell, the problem is that > the function arguments on parisc are sorted backwards (26, 25, 24, 23, > ...) compared to everyone else, so the calling conventions of using an > even/odd register pair in native word order result in the lower word > coming first in function arguments, matching the expected behavior > on little-endian architectures. The system call conventions however > ended up matching what the other 32-bit architectures do. > > A glibc cleanup in 2020 changed the userspace behavior in a way that > handles all architectures consistently, but this inadvertently broke > parisc32 by changing to the same method as everyone else. > > The change made it into glibc-2.35 and subsequently into debian 12 > (bookworm), which is the latest stable release. This means we > need to choose between reverting the glibc change or changing the > kernel to match it again, but either hange will leave some systems > broken. > > Pick the option that is more likely to help current and future > users and change the kernel to match current glibc. This also > means the behavior is now consistent across architectures, but > it breaks running new kernels with old glibc builds before 2.35. > > Link: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d150181d73d9 > Link: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/arch/parisc/kernel/sys_parisc.c?h=57b1dfbd5b4a39d > Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org> > Tested-by: Helge Deller <deller@gmx.de> > Acked-by: Helge Deller <deller@gmx.de> > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > I found this through code inspection, please double-check to make > sure I got the bug and the fix right. > Building parisc:allmodconfig ... failed -------------- Error log: In file included from fs/notify/fanotify/fanotify_user.c:14: include/linux/syscalls.h:248:25: error: conflicting types for 'sys_fanotify_mark'; have 'long int(int, unsigned int, u32, u32, int, const char *)' {aka 'long int(int, unsigned int, unsigned int, unsigned int, int, const char *)'} 248 | asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ | ^~~ include/linux/syscalls.h:234:9: note: in expansion of macro '__SYSCALL_DEFINEx' 234 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) | ^~~~~~~~~~~~~~~~~ include/linux/syscalls.h:228:36: note: in expansion of macro 'SYSCALL_DEFINEx' 228 | #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__) | ^~~~~~~~~~~~~~~ include/linux/syscalls.h:287:27: note: in expansion of macro 'SYSCALL_DEFINE6' 287 | #define SYSCALL32_DEFINE6 SYSCALL_DEFINE6 | ^~~~~~~~~~~~~~~ fs/notify/fanotify/fanotify_user.c:1924:1: note: in expansion of macro 'SYSCALL32_DEFINE6' 1924 | SYSCALL32_DEFINE6(fanotify_mark, | ^~~~~~~~~~~~~~~~~ include/linux/syscalls.h:862:17: note: previous declaration of 'sys_fanotify_mark' with type 'long int(int, unsigned int, u64, int, const char *)' {aka 'long int(int, unsigned int, long long unsigned int, int, const char *)'} 862 | asmlinkage long sys_fanotify_mark(int fanotify_fd, unsigned int flags, | ^~~~~~~~~~~~~~~~~ make[6]: [scripts/Makefile.build:244: fs/notify/fanotify/fanotify_user.o] Error 1 (ignored) Guenter
On Sat, Jun 29, 2024, at 19:46, Guenter Roeck wrote: > Building parisc:allmodconfig ... failed > -------------- > Error log: > In file included from fs/notify/fanotify/fanotify_user.c:14: > include/linux/syscalls.h:248:25: error: conflicting types for > 'sys_fanotify_mark'; have 'long int(int, unsigned int, u32, u32, > int, const char *)' {aka 'long int(int, unsigned int, unsigned int, > unsigned int, int, const char *)'} > 248 | asmlinkage long > sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ > | ^~~ > include/linux/syscalls.h:234:9: note: in expansion of macro > '__SYSCALL_DEFINEx' > 234 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) > | ^~~~~~~~~~~~~~~~~ Thanks for the report, this has escaped my build testing since I had fanotify disabled on the parisc build. Sent a fix now and queued it as a fix in the asm-generic tree: https://lore.kernel.org/lkml/20240629210359.94426-1-arnd@kernel.org/T/#u Arnd
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index daafeb20f993..dc9b902de8ea 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -16,6 +16,7 @@ config PARISC select ARCH_HAS_UBSAN select ARCH_HAS_PTE_SPECIAL select ARCH_NO_SG_CHAIN + select ARCH_SPLIT_ARG64 if !64BIT select ARCH_SUPPORTS_HUGETLBFS if PA20 select ARCH_SUPPORTS_MEMORY_FAILURE select ARCH_STACKWALK diff --git a/arch/parisc/kernel/sys_parisc32.c b/arch/parisc/kernel/sys_parisc32.c index 2a12a547b447..826c8e51b585 100644 --- a/arch/parisc/kernel/sys_parisc32.c +++ b/arch/parisc/kernel/sys_parisc32.c @@ -23,12 +23,3 @@ asmlinkage long sys32_unimplemented(int r26, int r25, int r24, int r23, current->comm, current->pid, r20); return -ENOSYS; } - -asmlinkage long sys32_fanotify_mark(compat_int_t fanotify_fd, compat_uint_t flags, - compat_uint_t mask0, compat_uint_t mask1, compat_int_t dfd, - const char __user * pathname) -{ - return sys_fanotify_mark(fanotify_fd, flags, - ((__u64)mask1 << 32) | mask0, - dfd, pathname); -} diff --git a/arch/parisc/kernel/syscalls/syscall.tbl b/arch/parisc/kernel/syscalls/syscall.tbl index 39e67fab7515..66dc406b12e4 100644 --- a/arch/parisc/kernel/syscalls/syscall.tbl +++ b/arch/parisc/kernel/syscalls/syscall.tbl @@ -364,7 +364,7 @@ 320 common accept4 sys_accept4 321 common prlimit64 sys_prlimit64 322 common fanotify_init sys_fanotify_init -323 common fanotify_mark sys_fanotify_mark sys32_fanotify_mark +323 common fanotify_mark sys_fanotify_mark compat_sys_fanotify_mark 324 32 clock_adjtime sys_clock_adjtime32 324 64 clock_adjtime sys_clock_adjtime 325 common name_to_handle_at sys_name_to_handle_at