|
Message-ID: <e22d7cd7-d247-4426-9506-a3a644ae03c4@cs-soprasteria.com> Date: Fri, 21 Jun 2024 05:26:27 +0000 From: LEROY Christophe <christophe.leroy2@...soprasteria.com> To: Helge Deller <deller@....de>, Arnd Bergmann <arnd@...nel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> CC: Arnd Bergmann <arnd@...db.de>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>, "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Andreas Larsson <andreas@...sler.com>, "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>, Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, Christophe Leroy <christophe.leroy@...roup.eu>, "Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>, "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, Brian Cain <bcain@...cinc.com>, "linux-hexagon@...r.kernel.org" <linux-hexagon@...r.kernel.org>, Guo Ren <guoren@...nel.org>, "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>, Heiko Carstens <hca@...ux.ibm.com>, "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>, Rich Felker <dalias@...c.org>, John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>, Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "libc-alpha@...rceware.org" <libc-alpha@...rceware.org>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, "ltp@...ts.linux.it" <ltp@...ts.linux.it>, Adhemerval Zanella <adhemerval.zanella@...aro.org> Subject: Re: [PATCH 07/15] parisc: use generic sys_fanotify_mark implementation Le 20/06/2024 à 23:21, Helge Deller a écrit : > [Vous ne recevez pas souvent de courriers de deller@....de. Découvrez > pourquoi ceci est important à > https://aka.ms/LearnAboutSenderIdentification ] > > On 6/20/24 18:23, Arnd Bergmann wrote: >> From: Arnd Bergmann <arnd@...db.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, > > r26 is arg0, r25 is arg1, and so on. > I'm not sure I would call this "sorted backwards". > I think the reason is simply that hppa is the only 32-bit big-endian > arch left... powerpc/32 is big-endian: r3 is arg0, r4 is arg1, ... r10 is arg7. In case of a 64bits arg, r3 is the high part and r4 is the low part. Christophe > >> 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. > > I appreciate such cleanups to make arches consistent. > But it's bad if breakages aren't noticed or reported then... > >> 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. > > Agreed (assuming we have really a problem on parisc). > >> 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@...aro.org> >> Signed-off-by: Arnd Bergmann <arnd@...db.de> >> --- >> I found this through code inspection, please double-check to make >> sure I got the bug and the fix right. > > The patch looks good at first sight. > I'll pick it up in my parisc git tree and will do some testing the > next few days and then push forward for 6.11 when it opens.... > > Thank you!! > > Helge > >> 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 >
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.