From: Arnd Bergmann <arnd@kernel.org>
To: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips@vger.kernel.org, Helge Deller <deller@gmx.de>,
linux-parisc@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
sparclinux@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"Naveen N . Rao" <naveen.n.rao@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, Brian Cain <bcain@quicinc.com>,
linux-hexagon@vger.kernel.org, Guo Ren <guoren@kernel.org>,
linux-csky@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
linux-s390@vger.kernel.org, Rich Felker <dalias@libc.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
linux-sh@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, libc-alpha@sourceware.org,
musl@lists.openwall.com,
Adhemerval Zanella <adhemerval.zanella@linaro.org>
Subject: [musl] [PATCH v2 06/13] parisc: use generic sys_fanotify_mark implementation
Date: Mon, 24 Jun 2024 18:37:04 +0200 [thread overview]
Message-ID: <20240624163707.299494-7-arnd@kernel.org> (raw)
In-Reply-To: <20240624163707.299494-1-arnd@kernel.org>
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.
The alternative is to fix this by reverting glibc back to the
unusual behavior.
---
arch/parisc/Kconfig | 1 +
arch/parisc/kernel/sys_parisc32.c | 9 ---------
arch/parisc/kernel/syscalls/syscall.tbl | 2 +-
3 files changed, 2 insertions(+), 10 deletions(-)
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
--
2.39.2
next prev parent reply other threads:[~2024-06-24 16:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 16:36 [musl] [PATCH v2 00/13] linux system call fixes Arnd Bergmann
2024-06-24 16:36 ` [musl] [PATCH v2 01/13] ftruncate: pass a signed offset Arnd Bergmann
2024-06-24 16:37 ` [musl] [PATCH v2 02/13] syscalls: fix compat_sys_io_pgetevents_time64 usage Arnd Bergmann
2024-06-24 16:37 ` [musl] [PATCH v2 03/13] sparc: fix old compat_sys_select() Arnd Bergmann
2024-06-24 16:37 ` [musl] [PATCH v2 04/13] sparc: fix compat recv/recvfrom syscalls Arnd Bergmann
2024-06-24 16:37 ` [musl] [PATCH v2 05/13] parisc: use correct " Arnd Bergmann
2024-06-24 16:37 ` Arnd Bergmann [this message]
2024-06-29 17:46 ` [musl] Re: [PATCH v2 06/13] parisc: use generic sys_fanotify_mark implementation Guenter Roeck
2024-06-29 21:05 ` Arnd Bergmann
2024-06-24 16:37 ` [musl] [PATCH v2 07/13] powerpc: restore some missing spu syscalls Arnd Bergmann
2024-06-24 16:37 ` [musl] [PATCH v2 08/13] sh: rework sync_file_range ABI Arnd Bergmann
2024-06-25 6:11 ` [musl] " John Paul Adrian Glaubitz
2024-06-24 16:37 ` [musl] [PATCH v2 09/13] csky, hexagon: fix broken sys_sync_file_range Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240624163707.299494-7-arnd@kernel.org \
--to=arnd@kernel.org \
--cc=adhemerval.zanella@linaro.org \
--cc=andreas@gaisler.com \
--cc=arnd@arndb.de \
--cc=bcain@quicinc.com \
--cc=brauner@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=glaubitz@physik.fu-berlin.de \
--cc=guoren@kernel.org \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=musl@lists.openwall.com \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).