hppa: Wire up cacheflush syscall
Checks
Context |
Check |
Description |
redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
redhat-pt-bot/TryBot-32bit |
success
|
Build for i686
|
linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Build passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Test passed
|
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Build passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
success
|
Test passed
|
redhat-pt-bot/TryBot-still_applies |
warning
|
Patch no longer applies to master
|
Commit Message
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>
---
Comments
* 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
@@ -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
@@ -23,4 +23,7 @@ libc {
GLIBC_2.19 {
fanotify_mark;
}
+ GLIBC_2.40 {
+ cacheflush;
+ }
}
@@ -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
new file mode 100644
@@ -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 */
@@ -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