| Message ID | Zos8gVaGUcuaaNaI@carbonx1 |
|---|---|
| State | New |
| Headers | show |
| Series | hppa: Wire up cacheflush syscall | expand |
* Helge Deller: > diff --git a/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h > new file mode 100644 > index 0000000000..16e47d1329 > --- /dev/null > +++ b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h > @@ -0,0 +1,36 @@ > +#ifndef _SYS_CACHECTL_H > +#define _SYS_CACHECTL_H 1 > + > +#include <features.h> > + > +/* Get the kernel definition for the op bits. */ > +#include <asm/cachectl.h> This makes this header (<sys/cachectl.h>) unusable with older kernel headers. I think it also results in a test failure with older headers. Is this a problem? In similar cases, we use LINUX_VERSION_CODE checks (for older compilers) and __has_include to support backports. Thanks, Florian
On 7/8/24 10:13, Florian Weimer wrote: > * Helge Deller: > >> diff --git a/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h >> new file mode 100644 >> index 0000000000..16e47d1329 >> --- /dev/null >> +++ b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h >> @@ -0,0 +1,36 @@ > >> +#ifndef _SYS_CACHECTL_H >> +#define _SYS_CACHECTL_H 1 >> + >> +#include <features.h> >> + >> +/* Get the kernel definition for the op bits. */ >> +#include <asm/cachectl.h> > > This makes this header (<sys/cachectl.h>) unusable with older kernel > headers. I think it also results in a test failure with older headers. > Is this a problem? hppa lives in debian unstable, so basically you should always use the latest kernel & kernel headers when upgrading glibc. So, personally I think it's ok to ask people to upgrade. Dave, any opinion on this? > In similar cases, we use LINUX_VERSION_CODE checks (for older compilers) > and __has_include to support backports. I'd prefer to not add additional checks. Another (maybe easier) possibility is to simply backport the kernel asm/cachectl.h file (just the header, not the implementation, so the syscall will return -ENOSYS on older kernels): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c6d96328fecdda16e12f3b3c33f3677f4bcef89f Helge
Am Montag, 8. Juli 2024, 10:58:35 CEST schrieb Helge Deller: > On 7/8/24 10:13, Florian Weimer wrote: > > * Helge Deller: > > > >> diff --git a/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h > >> new file mode 100644 > >> index 0000000000..16e47d1329 > >> --- /dev/null > >> +++ b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h > >> @@ -0,0 +1,36 @@ > > > >> +#ifndef _SYS_CACHECTL_H > >> +#define _SYS_CACHECTL_H 1 > >> + > >> +#include <features.h> > >> + > >> +/* Get the kernel definition for the op bits. */ > >> +#include <asm/cachectl.h> > > > > This makes this header (<sys/cachectl.h>) unusable with older kernel > > headers. I think it also results in a test failure with older headers. > > Is this a problem? > > hppa lives in debian unstable, so basically you should always use > the latest kernel & kernel headers when upgrading glibc. Ahem. https://www.gentoo.org/downloads/#hppa > So, personally I think it's ok to ask people to upgrade. > Dave, any opinion on this? > > > In similar cases, we use LINUX_VERSION_CODE checks (for older compilers) > > and __has_include to support backports. > > I'd prefer to not add additional checks. > Another (maybe easier) possibility is to simply backport the kernel asm/cachectl.h > file (just the header, not the implementation, so the syscall will return -ENOSYS on > older kernels): > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c6d96328fecdda16e12f3b3c33f3677f4bcef89f > > Helge >
On 7/8/24 18:00, Andreas K. Huettel wrote: > Am Montag, 8. Juli 2024, 10:58:35 CEST schrieb Helge Deller: >> On 7/8/24 10:13, Florian Weimer wrote: >>> * Helge Deller: >>> >>>> diff --git a/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h >>>> new file mode 100644 >>>> index 0000000000..16e47d1329 >>>> --- /dev/null >>>> +++ b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h >>>> @@ -0,0 +1,36 @@ >>> >>>> +#ifndef _SYS_CACHECTL_H >>>> +#define _SYS_CACHECTL_H 1 >>>> + >>>> +#include <features.h> >>>> + >>>> +/* Get the kernel definition for the op bits. */ >>>> +#include <asm/cachectl.h> >>> >>> This makes this header (<sys/cachectl.h>) unusable with older kernel >>> headers. I think it also results in a test failure with older headers. >>> Is this a problem? >> >> hppa lives in debian unstable, so basically you should always use >> the latest kernel & kernel headers when upgrading glibc. > > Ahem. > https://www.gentoo.org/downloads/#hppa Sure. But I didn't mentioned it, because Gentoo usually uses a more recent kernel than Debian, right? Helge
Helge Deller <deller@gmx.de> writes: > On 7/8/24 18:00, Andreas K. Huettel wrote: >> Am Montag, 8. Juli 2024, 10:58:35 CEST schrieb Helge Deller: >>> On 7/8/24 10:13, Florian Weimer wrote: >>>> * Helge Deller: >>>> >>>>> diff --git a/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h >>>>> new file mode 100644 >>>>> index 0000000000..16e47d1329 >>>>> --- /dev/null >>>>> +++ b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h >>>>> @@ -0,0 +1,36 @@ >>>> >>>>> +#ifndef _SYS_CACHECTL_H >>>>> +#define _SYS_CACHECTL_H 1 >>>>> + >>>>> +#include <features.h> >>>>> + >>>>> +/* Get the kernel definition for the op bits. */ >>>>> +#include <asm/cachectl.h> >>>> >>>> This makes this header (<sys/cachectl.h>) unusable with older kernel >>>> headers. I think it also results in a test failure with older headers. >>>> Is this a problem? >>> >>> hppa lives in debian unstable, so basically you should always use >>> the latest kernel & kernel headers when upgrading glibc. >> >> Ahem. >> https://www.gentoo.org/downloads/#hppa > > Sure. But I didn't mentioned it, because Gentoo usually uses a > more recent kernel than Debian, right? > In this instance, I wonder if we should do the extra checks. The kernel instability because of the cache / TLB issues means at least one of our machines runs an older kernel for now. (Dave's latest patches seem to help a lot there, but you get the point.) thanks, sam
On 2024-07-09 9:41 a.m., Sam James wrote: > In this instance, I wonder if we should do the extra checks. The kernel > instability because of the cache / TLB issues means at least one of our > machines runs an older kernel for now. (Dave's latest patches seem to > help a lot there, but you get the point.) Can you be more specific? Do you still experience instability due to cache / TLB issues on this machine? Dave
John David Anglin <dave.anglin@bell.net> writes: > On 2024-07-09 9:41 a.m., Sam James wrote: >> In this instance, I wonder if we should do the extra checks. The kernel >> instability because of the cache / TLB issues means at least one of our >> machines runs an older kernel for now. (Dave's latest patches seem to >> help a lot there, but you get the point.) > Can you be more specific? Do you still experience instability due to cache / TLB issues > on this machine? Sorry for the delay. Our main machine, 'muta', has been suffering instability for a while. It ended up also having bad RAM and failing disks. We've now replaced them last night. We had a lot of kernel crashes since then but after upgrading to 6.10.11, everything seems okay so far. Fingers crossed, and then I can get back to the other bits (like testing the binutils patch). (The panics were all in pte_offset_map_nolock.) > > Dave thanks, sam
On 9/26/24 21:08, Sam James wrote: > John David Anglin <dave.anglin@bell.net> writes: > >> On 2024-07-09 9:41 a.m., Sam James wrote: >>> In this instance, I wonder if we should do the extra checks. The kernel >>> instability because of the cache / TLB issues means at least one of our >>> machines runs an older kernel for now. (Dave's latest patches seem to >>> help a lot there, but you get the point.) >> Can you be more specific? Do you still experience instability due to cache / TLB issues >> on this machine? > > Sorry for the delay. Our main machine, 'muta', has been suffering > instability for a while. It ended up also having bad RAM and failing > disks. We've now replaced them last night. > > We had a lot of kernel crashes since then but after upgrading to > 6.10.11, everything seems okay so far. FYI, Dave's commit 72d95924ee35 ("parisc: Try to fix random segmentation faults in package builds") [1] was a game-changer for the parisc kernel. It went into kernel 6.10 and since then our 64-bit debian builds run absolutely stable. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72d95924ee35c8cd16ef52f912483ee938a34d49
diff --git a/sysdeps/unix/sysv/linux/hppa/Makefile b/sysdeps/unix/sysv/linux/hppa/Makefile index 2e031e2f8a..9eebe8e0e7 100644 --- a/sysdeps/unix/sysv/linux/hppa/Makefile +++ b/sysdeps/unix/sysv/linux/hppa/Makefile @@ -15,6 +15,11 @@ test-xfail-check-wx-segment = * endif # $(subdir) == elf +ifeq ($(subdir),misc) +sysdep_routines += cacheflush +sysdep_headers += sys/cachectl.h +endif + ifeq ($(subdir),debug) test-xfail-tst-ssp-1 = $(have-ssp) endif # $(subdir) == debug diff --git a/sysdeps/unix/sysv/linux/hppa/Versions b/sysdeps/unix/sysv/linux/hppa/Versions index 78528e5fa2..f7ac20ab7e 100644 --- a/sysdeps/unix/sysv/linux/hppa/Versions +++ b/sysdeps/unix/sysv/linux/hppa/Versions @@ -23,4 +23,7 @@ libc { GLIBC_2.19 { fanotify_mark; } + GLIBC_2.40 { + cacheflush; + } } diff --git a/sysdeps/unix/sysv/linux/hppa/libc.abilist b/sysdeps/unix/sysv/linux/hppa/libc.abilist index fbcd60c2b3..965b946ab0 100644 --- a/sysdeps/unix/sysv/linux/hppa/libc.abilist +++ b/sysdeps/unix/sysv/linux/hppa/libc.abilist @@ -2821,6 +2821,7 @@ GLIBC_2.4 sys_errlist D 0x400 GLIBC_2.4 sys_nerr D 0x4 GLIBC_2.4 unlinkat F GLIBC_2.4 unshare F +GLIBC_2.40 cacheflush F GLIBC_2.5 __readlinkat_chk F GLIBC_2.5 inet6_opt_append F GLIBC_2.5 inet6_opt_find F diff --git a/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h new file mode 100644 index 0000000000..16e47d1329 --- /dev/null +++ b/sysdeps/unix/sysv/linux/hppa/sys/cachectl.h @@ -0,0 +1,36 @@ +/* HPPA cache flushing interface. + Copyright (C) 2018-2024 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library. If not, see + <https://www.gnu.org/licenses/>. */ + +#ifndef _SYS_CACHECTL_H +#define _SYS_CACHECTL_H 1 + +#include <features.h> + +/* Get the kernel definition for the op bits. */ +#include <asm/cachectl.h> + +__BEGIN_DECLS + +#ifdef __USE_MISC +extern int cacheflush (void *__addr, const int __nbytes, + const int __op) __THROW; +#endif + +__END_DECLS + +#endif /* sys/cachectl.h */ diff --git a/sysdeps/unix/sysv/linux/hppa/syscalls.list b/sysdeps/unix/sysv/linux/hppa/syscalls.list index 12e4adeccc..b3020114d6 100644 --- a/sysdeps/unix/sysv/linux/hppa/syscalls.list +++ b/sysdeps/unix/sysv/linux/hppa/syscalls.list @@ -8,5 +8,6 @@ listen - listen i:ii __listen listen shutdown - shutdown i:ii __shutdown shutdown socket - socket i:iii __socket socket socketpair - socketpair i:iiif __socketpair socketpair +cacheflush - cacheflush i:pii _flush_cache cacheflush personality EXTRA personality Ei:i __personality personality
The hppa Linux kernel supports the cacheflush() syscall since version 6.5. This adds the glibc syscall wrapper. Signed-off-by: Helge Deller <deller@gmx.de> ---