From: Guenter Roeck <linux@roeck-us.net>
To: Arnd Bergmann <arnd@kernel.org>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
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] Re: [PATCH v2 06/13] parisc: use generic sys_fanotify_mark implementation
Date: Sat, 29 Jun 2024 10:46:33 -0700 [thread overview]
Message-ID: <a913c77e-1abb-409f-86b9-8805c1451988@roeck-us.net> (raw)
In-Reply-To: <20240624163707.299494-7-arnd@kernel.org>
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
next prev parent reply other threads:[~2024-06-29 18:00 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 ` [musl] [PATCH v2 06/13] parisc: use generic sys_fanotify_mark implementation Arnd Bergmann
2024-06-29 17:46 ` Guenter Roeck [this message]
2024-06-29 21:05 ` [musl] " 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=a913c77e-1abb-409f-86b9-8805c1451988@roeck-us.net \
--to=linux@roeck-us.net \
--cc=adhemerval.zanella@linaro.org \
--cc=andreas@gaisler.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--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).