Re: [PATCH v2 06/13] parisc: use generic sys_fanotify_mark implementation

Guenter Roeck <[email protected]>
Newsgroups gmane.linux.ports.hexagon,gmane.linux.kernel.cross-arch,gmane.linux.kernel,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.sparc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.sh.devel,gmane.linux.file-systems,gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general
Message-ID <[email protected]>
On Mon, Jun 24, 2024 at 06:37:04PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
> 
> 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 <[email protected]>
> Tested-by: Helge Deller <[email protected]>
> Acked-by: Helge Deller <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.