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

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

[Helge Deller]

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>

---

diff --git a/sysdeps/unix/sysv/linux/hppa/bits/mman.h b/sysdeps/unix/sysv/linux/hppa/bits/mman.h
index c315efceb0..f5a69693af 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/mman.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/mman.h
@@ -39,11 +39,6 @@
 #define MAP_FIXED_NOREPLACE 0x100000	/* MAP_FIXED but do not unmap
 					   underlying mapping.  */

-/* Advice to "madvise"  */
-#ifdef __USE_MISC
-# define MADV_SOFT_OFFLINE 101	/* Soft offline page for testing.  */
-#endif
-
 #include <bits/mman-linux.h>

 #undef MAP_TYPE
@@ -59,26 +54,3 @@
 #define MS_ASYNC	2		/* Sync memory asynchronously */
 #undef MS_INVALIDATE
 #define MS_INVALIDATE	4		/* Invalidate the caches */
-
-/* Advice to "madvise"  */
-#ifdef __USE_MISC
-# undef MADV_MERGEABLE
-# define MADV_MERGEABLE   65	/* KSM may merge identical pages */
-# undef MADV_UNMERGEABLE
-# define MADV_UNMERGEABLE 66	/* KSM may not merge identical pages */
-# undef MADV_HUGEPAGE
-# define MADV_HUGEPAGE	 67	/* Worth backing with hugepages */
-# undef MADV_NOHUGEPAGE
-# define MADV_NOHUGEPAGE 68	/* Not worth backing with hugepages */
-# undef MADV_DONTDUMP
-# define MADV_DONTDUMP	 69	/* Explicity exclude from the core dump,
-				   overrides the coredump filter bits */
-# undef MADV_DODUMP
-# define MADV_DODUMP	 70	/* Clear the MADV_NODUMP flag */
-# undef MADV_WIPEONFORK
-# define MADV_WIPEONFORK 71	/* Zero memory on fork, child only.  */
-# undef MADV_KEEPONFORK
-# define MADV_KEEPONFORK 72	/* Undo MADV_WIPEONFORK.  */
-# undef MADV_COLLAPSE
-# define MADV_COLLAPSE   73	/* Synchronous hugepage collapse.  */
-#endif

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

[Florian Weimer]

* Helge Deller via Libc-alpha:

> 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.

What about qemu-user?  Maybe it has always worked?

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

I appreciate the simplification, but I think this needs a NEWS file
update, spelling out the required kernel versions on hppa if the madvise
function is used.

Thanks,
Florian

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

[Helge Deller]

On 2/10/23 11:18, Florian Weimer wrote:
> * Helge Deller via Libc-alpha:
>
>> 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.
>
> What about qemu-user?  Maybe it has always worked?

qemu-user was broken before, which is why I noticed that difference at all,
and which is the reason I came up with the kernel patch.
I did sent a fix for qemu-user too, which was applied some days ago:
https://gitlab.com/qemu-project/qemu/-/commit/4530deb1fe81152ae2384a56eb7edb5467f894fa

>> This patch now drops the parisc specific constants from glibc to
>> allow newly compliled programs to use the standard MADV_* constants.
>
> I appreciate the simplification, but I think this needs a NEWS file
> update, spelling out the required kernel versions on hppa if the madvise
> function is used.

Maybe add to the "Deprecated and removed features, and other changes affecting compatibility:"
section something like this?

* In the Linux kernel for the hppa/parisc architecture some of the MADV_ 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 kernels version 6.2, alternatively stable kernels
   from version 6.1.6, version 5.15.87 or version 5.10.163.

Helge

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

[Helge Deller]

On 2/10/23 11:48, Helge Deller wrote:
> On 2/10/23 11:18, Florian Weimer wrote:
>> * Helge Deller via Libc-alpha:
>>
>>> 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.
>>
>> What about qemu-user?  Maybe it has always worked?
>
> qemu-user was broken before, which is why I noticed that difference at all,
> and which is the reason I came up with the kernel patch.
> I did sent a fix for qemu-user too, which was applied some days ago:
> https://gitlab.com/qemu-project/qemu/-/commit/4530deb1fe81152ae2384a56eb7edb5467f894fa
>
>>> This patch now drops the parisc specific constants from glibc to
>>> allow newly compliled programs to use the standard MADV_* constants.
>>
>> I appreciate the simplification, but I think this needs a NEWS file
>> update, spelling out the required kernel versions on hppa if the madvise
>> function is used.
>
> Maybe add to the "Deprecated and removed features, and other changes affecting compatibility:"
> section something like this?
>
> * In the Linux kernel for the hppa/parisc architecture some of the MADV_ 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 kernels version 6.2, alternatively stable kernels
>    from version 6.1.6, version 5.15.87 or version 5.10.163.

and 5.4.228, 4.19.270, 4.14.303

Helge

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

[Florian Weimer]

* Helge Deller:

> qemu-user was broken before, which is why I noticed that difference at all,
> and which is the reason I came up with the kernel patch.
> I did sent a fix for qemu-user too, which was applied some days ago:
> https://gitlab.com/qemu-project/qemu/-/commit/4530deb1fe81152ae2384a56eb7edb5467f894fa

Thanks for providing this context.

>>> This patch now drops the parisc specific constants from glibc to
>>> allow newly compliled programs to use the standard MADV_* constants.
>>
>> I appreciate the simplification, but I think this needs a NEWS file
>> update, spelling out the required kernel versions on hppa if the madvise
>> function is used.
>
> Maybe add to the "Deprecated and removed features, and other changes
> affecting compatibility:" section something like this?

Yes, exactly.

> * In the Linux kernel for the hppa/parisc architecture some of the MADV_ 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 kernels version 6.2, alternatively stable kernels
>   from version 6.1.6, version 5.15.87 or version 5.10.163.

Shorter lines please, and no () after function names in
documentation. 8-)  Rest looks fine.

Thanks,
Florian