[v2] hppa: Drop old parisc-specific MADV_* constants

The Linux kernel upstream commit 71bdea6f798b ("parisc: Align parisc
MADV_XXX constants with all other architectures") dropped the
parisc-specific MADV_* values in favour of the same constants as
other architectures. In the same commit a wrapper was added which
translates the old values to the standard MADV_* values to avoid
breakage of existing programs.
This upstream patch has been downported to all stable kernel trees as
well.

This patch now drops the parisc specific constants from glibc to
allow newly compliled programs to use the standard MADV_* constants.

Signed-off-by: Helge Deller <deller@gmx.de>

---
v2: Added NEWS section, based on feedback from Florian Weimer

On Fri, 10 Feb 2023, Helge Deller via Libc-alpha wrote:

> -  [Add deprecations, removals and changes affecting compatibility here]
> +* In the Linux kernel for the hppa/parisc architecture some of the
> +  MADV_XXX constants were changed to have the same values as the other
> +  architectures.  New programs compiled with this glibc version and which
> +  use the madvise call will require at least Linux kernel version 6.2,
> +  alternatively stable kernels from versions 6.1.6, 5.15.87, 5.10.163,
> +  5.4.228, 4.19.270 or 4.14.303.

Normally we'd be a lot more conservative about kernel version 
requirements, but if we require a new kernel we'd put it in 
arch_minimum_kernel in the relevant configure.ac.

On 2/10/23 22:48, Joseph Myers wrote:
> On Fri, 10 Feb 2023, Helge Deller via Libc-alpha wrote:
>
>> -  [Add deprecations, removals and changes affecting compatibility here]
>> +* In the Linux kernel for the hppa/parisc architecture some of the
>> +  MADV_XXX constants were changed to have the same values as the other
>> +  architectures.  New programs compiled with this glibc version and which
>> +  use the madvise call will require at least Linux kernel version 6.2,
>> +  alternatively stable kernels from versions 6.1.6, 5.15.87, 5.10.163,
>> +  5.4.228, 4.19.270 or 4.14.303.
>
> Normally we'd be a lot more conservative about kernel version
> requirements, but if we require a new kernel we'd put it in
> arch_minimum_kernel in the relevant configure.ac.

Basically, programs compiled with the new MADV values should work even
on all older kernels since it's just an advise for the kernel which it may
ignore and for which programs should allow the syscall to fail.
The only program I've found so far to be more strict is the
tor-browser, which refuses to start if MADV_WIPEONFORK fails.
But it's unlikely people will use tor on parisc, and IMHO
if you care about security you should use a more recent kernel anyway.

That said, I can add arch_minimum_kernel=4.14.303 (or 6.2?) but I don't
think it's necessary.

Helge

On 2023-02-11 1:37 a.m., Helge Deller wrote:
> On 2/10/23 22:48, Joseph Myers wrote:
>> On Fri, 10 Feb 2023, Helge Deller via Libc-alpha wrote:
>>
>>> -  [Add deprecations, removals and changes affecting compatibility here]
>>> +* In the Linux kernel for the hppa/parisc architecture some of the
>>> +  MADV_XXX constants were changed to have the same values as the other
>>> +  architectures.  New programs compiled with this glibc version and which
>>> +  use the madvise call will require at least Linux kernel version 6.2,
>>> +  alternatively stable kernels from versions 6.1.6, 5.15.87, 5.10.163,
>>> +  5.4.228, 4.19.270 or 4.14.303.
>>
>> Normally we'd be a lot more conservative about kernel version
>> requirements, but if we require a new kernel we'd put it in
>> arch_minimum_kernel in the relevant configure.ac.
>
> Basically, programs compiled with the new MADV values should work even
> on all older kernels since it's just an advise for the kernel which it may
> ignore and for which programs should allow the syscall to fail.
> The only program I've found so far to be more strict is the
> tor-browser, which refuses to start if MADV_WIPEONFORK fails.
> But it's unlikely people will use tor on parisc, and IMHO
> if you care about security you should use a more recent kernel anyway.
>
> That said, I can add arch_minimum_kernel=4.14.303 (or 6.2?) but I don't
> think it's necessary.
I don't think adding a arch_minimum_kernel define would help much. I don't know about
gentoo, but the current Debian kernel for hppa is already past the minimum for the new values.

The biggest risk is for people like me that keep a collection of old kernels around to check
for regressions in behavior.  As long as there is no major breakage with old kernels running
new applications, we can make the switch.

Dave

On Fri, 10 Feb 2023, Helge Deller via Libc-alpha wrote:

> The Linux kernel upstream commit 71bdea6f798b ("parisc: Align parisc
> MADV_XXX constants with all other architectures") dropped the
> parisc-specific MADV_* values in favour of the same constants as
> other architectures. In the same commit a wrapper was added which

I'd like to enquire about another part of that commit.  It removes the 
#define of MAP_VARIABLE to 0, so resulting in tst-mman-consts failing if I 
update build-many-glibcs.py to use Linux 6.2.  So we'll need to change 
tst-mman-consts.py to allow variation between userspace and kernel 
regarding whether that macro is defined (the expectation of the test being 
that newer kernels only add macros tested for, not remove them), but 
should we also remove that define in glibc?

Hi Joseph,

On 2/22/23 16:35, Joseph Myers wrote:
> On Fri, 10 Feb 2023, Helge Deller via Libc-alpha wrote:
>
>> The Linux kernel upstream commit 71bdea6f798b ("parisc: Align parisc
>> MADV_XXX constants with all other architectures") dropped the
>> parisc-specific MADV_* values in favour of the same constants as
>> other architectures. In the same commit a wrapper was added which
>
> I'd like to enquire about another part of that commit.  It removes the
> #define of MAP_VARIABLE to 0, so resulting in tst-mman-consts failing if I
> update build-many-glibcs.py to use Linux 6.2.

Oh, didn't knew that.
Basically it wasn't necessary to drop MAP_VARIABLE, but since no other arch
defined it either and as it's not used anywhere in the kernel I assumed it's
ok to drop it.

> So we'll need to change
> tst-mman-consts.py to allow variation between userspace and kernel
> regarding whether that macro is defined (the expectation of the test being
> that newer kernels only add macros tested for, not remove them), but
> should we also remove that define in glibc?

Yes, I think that's the best solution. Keeps glibc and kernel in sync.

Thank you!
Helge