Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-17 Thread Yann Droneaud
Hi,

Le mercredi 16 mai 2018 à 15:20 +0100, Dave Martin a écrit :
> There are constraints on defining AT_* auxvec tags that are not
> obvious to the casual maintainer of either the global
>  or the arch-specific headers.  This is likely
> to lead to mistakes.  (I certainly fell foul of it...)
> 
> For the benefit of future maintainers, this patch collects the
> relevant information in one place, documenting how the namespace
> needs to be managed, and noting all the values currently in use.
> 
> Maintaining a global list may result in some merge conflicts, but
> AT_* values are not added frequently.  I'm open to suggestions on
> the best approach.
> 
> I also assume that values 38 and 39 may have been used for
> historical purposes, such as an architecture that is no longer
> supported.  If they have definitely never been used for anything,
> they could be removed from the "reserved" list.
> 

Some of those AT_* values are described in getauxval(3) man-page:

http://man7.org/linux/man-pages/man3/getauxval.3.html

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/g
etauxval.3?id=4eae8eb731386d81797d5c30365426722410874e

And glibc provides  with definitions for almost all AT_*,
regardless of the current target architecture:

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h;h=954f3266f7
11ab83996670ea504a17dcf668e061;hb=23158b08a0908f381459f273a984c6fd32836
3cb#l1135

Also, despite not being listed as a reserved namespace by POSIX, one
should try to avoid name collision with other AT_ constants,
those used with *at() functions (openat(), etc.):

- AT_EACCESS 
- AT_EMPTY_PATH
- AT_FDCWD
- AT_NO_AUTOMOUNT
- AT_REMOVEDIR
- AT_STATX_DONT_SYNC
- AT_STATX_FORCE_SYNC
- AT_STATX_SYNC_AS_STAT
- AT_SYMLINK_FOLLOW
- AT_SYMLINK_NOFOLLOW

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.htm
l#tag_15_02_02

https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fcntl.h;h=3d239e8f0
9f7ce0a3106621be327e1ea4cd1a3e7;hb=23158b08a0908f381459f273a984c6fd3283
63cb#l142

And there's also AT_ANYNET and AT_ANYNODE from ddp (aka. AppleTalk)

http://man7.org/linux/man-pages/man7/ddp.7.html

Regards.

-- 
Yann Droneaud
OPTEYA



Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-17 Thread Yann Droneaud
Hi,

Le mercredi 16 mai 2018 à 15:20 +0100, Dave Martin a écrit :
> There are constraints on defining AT_* auxvec tags that are not
> obvious to the casual maintainer of either the global
>  or the arch-specific headers.  This is likely
> to lead to mistakes.  (I certainly fell foul of it...)
> 
> For the benefit of future maintainers, this patch collects the
> relevant information in one place, documenting how the namespace
> needs to be managed, and noting all the values currently in use.
> 
> Maintaining a global list may result in some merge conflicts, but
> AT_* values are not added frequently.  I'm open to suggestions on
> the best approach.
> 
> I also assume that values 38 and 39 may have been used for
> historical purposes, such as an architecture that is no longer
> supported.  If they have definitely never been used for anything,
> they could be removed from the "reserved" list.
> 

Some of those AT_* values are described in getauxval(3) man-page:

http://man7.org/linux/man-pages/man3/getauxval.3.html

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/g
etauxval.3?id=4eae8eb731386d81797d5c30365426722410874e

And glibc provides  with definitions for almost all AT_*,
regardless of the current target architecture:

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h;h=954f3266f7
11ab83996670ea504a17dcf668e061;hb=23158b08a0908f381459f273a984c6fd32836
3cb#l1135

Also, despite not being listed as a reserved namespace by POSIX, one
should try to avoid name collision with other AT_ constants,
those used with *at() functions (openat(), etc.):

- AT_EACCESS 
- AT_EMPTY_PATH
- AT_FDCWD
- AT_NO_AUTOMOUNT
- AT_REMOVEDIR
- AT_STATX_DONT_SYNC
- AT_STATX_FORCE_SYNC
- AT_STATX_SYNC_AS_STAT
- AT_SYMLINK_FOLLOW
- AT_SYMLINK_NOFOLLOW

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.htm
l#tag_15_02_02

https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fcntl.h;h=3d239e8f0
9f7ce0a3106621be327e1ea4cd1a3e7;hb=23158b08a0908f381459f273a984c6fd3283
63cb#l142

And there's also AT_ANYNET and AT_ANYNODE from ddp (aka. AppleTalk)

http://man7.org/linux/man-pages/man7/ddp.7.html

Regards.

-- 
Yann Droneaud
OPTEYA



Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-17 Thread Michael Ellerman
Dave Martin  writes:

> There are constraints on defining AT_* auxvec tags that are not
> obvious to the casual maintainer of either the global
>  or the arch-specific headers.  This is likely
> to lead to mistakes.  (I certainly fell foul of it...)

Thanks for cleaning this up.

It looks like us (powerpc) / me is the main offender here.

My excuse is it was glibc folk who asked us to add all those new AT_
entries in the first place. 

> For the benefit of future maintainers, this patch collects the
> relevant information in one place, documenting how the namespace
> needs to be managed, and noting all the values currently in use.
>
> Maintaining a global list may result in some merge conflicts, but
> AT_* values are not added frequently.  I'm open to suggestions on
> the best approach.

Yeah I agree with Rich that having a global list would be best. That is
the most reliable to make people think twice about adding new entries.

> I also assume that values 38 and 39 may have been used for
> historical purposes, such as an architecture that is no longer
> supported.  If they have definitely never been used for anything,
> they could be removed from the "reserved" list.

I don't know why we added the new entries starting at 40, maybe Ben
remembers. Quite likely it was just an accident.

I don't see any sign of 38 or 39 in glibc history.

cheers


Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-17 Thread Michael Ellerman
Dave Martin  writes:

> There are constraints on defining AT_* auxvec tags that are not
> obvious to the casual maintainer of either the global
>  or the arch-specific headers.  This is likely
> to lead to mistakes.  (I certainly fell foul of it...)

Thanks for cleaning this up.

It looks like us (powerpc) / me is the main offender here.

My excuse is it was glibc folk who asked us to add all those new AT_
entries in the first place. 

> For the benefit of future maintainers, this patch collects the
> relevant information in one place, documenting how the namespace
> needs to be managed, and noting all the values currently in use.
>
> Maintaining a global list may result in some merge conflicts, but
> AT_* values are not added frequently.  I'm open to suggestions on
> the best approach.

Yeah I agree with Rich that having a global list would be best. That is
the most reliable to make people think twice about adding new entries.

> I also assume that values 38 and 39 may have been used for
> historical purposes, such as an architecture that is no longer
> supported.  If they have definitely never been used for anything,
> they could be removed from the "reserved" list.

I don't know why we added the new entries starting at 40, maybe Ben
remembers. Quite likely it was just an accident.

I don't see any sign of 38 or 39 in glibc history.

cheers


Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Rich Felker
On Wed, May 16, 2018 at 04:09:29PM -0700, H. Peter Anvin wrote:
> On 05/16/18 08:49, Dave Martin wrote:
> > 
> > Since  only contains #defines, it may be enough for arch
> >  headers to include .
> > 
> 
>  doesn't seem to have any reason to exist at all. If
> anyone includes it now, they are Doing It Wrong[TM] since
>  includes .

Sounds good. BTW there probably does need to be a check for
kernel-internal use of #ifdef AT_* etc. I saw some instances in
arch/um and a few other weird places. They might not matter but there
might be code that's indirectly enabled only for certain archs via the
AT_* macros.

Rich


Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Rich Felker
On Wed, May 16, 2018 at 04:09:29PM -0700, H. Peter Anvin wrote:
> On 05/16/18 08:49, Dave Martin wrote:
> > 
> > Since  only contains #defines, it may be enough for arch
> >  headers to include .
> > 
> 
>  doesn't seem to have any reason to exist at all. If
> anyone includes it now, they are Doing It Wrong[TM] since
>  includes .

Sounds good. BTW there probably does need to be a check for
kernel-internal use of #ifdef AT_* etc. I saw some instances in
arch/um and a few other weird places. They might not matter but there
might be code that's indirectly enabled only for certain archs via the
AT_* macros.

Rich


Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread H. Peter Anvin
On 05/16/18 08:49, Dave Martin wrote:
> 
> Since  only contains #defines, it may be enough for arch
>  headers to include .
> 

 doesn't seem to have any reason to exist at all. If
anyone includes it now, they are Doing It Wrong[TM] since
 includes .

-hpa



Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread H. Peter Anvin
On 05/16/18 08:49, Dave Martin wrote:
> 
> Since  only contains #defines, it may be enough for arch
>  headers to include .
> 

 doesn't seem to have any reason to exist at all. If
anyone includes it now, they are Doing It Wrong[TM] since
 includes .

-hpa



Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Dave Martin
On Wed, May 16, 2018 at 11:29:13AM -0400, Rich Felker wrote:
> On Wed, May 16, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> > There are constraints on defining AT_* auxvec tags that are not
> > obvious to the casual maintainer of either the global
> >  or the arch-specific headers.  This is likely
> > to lead to mistakes.  (I certainly fell foul of it...)
> > 
> > For the benefit of future maintainers, this patch collects the
> > relevant information in one place, documenting how the namespace
> > needs to be managed, and noting all the values currently in use.
> > 
> > Maintaining a global list may result in some merge conflicts, but
> > AT_* values are not added frequently.  I'm open to suggestions on
> > the best approach.
> > 
> > I also assume that values 38 and 39 may have been used for
> > historical purposes, such as an architecture that is no longer
> > supported.  If they have definitely never been used for anything,
> > they could be removed from the "reserved" list.
> 
> On the userspace side (elf.h) all the AT_* constants are in one file.
> Why don't we just do the same here and eliminate the
> arch/*/include/uapi/asm/auxvec.h files and likewise the need to
> manually maintain consistency of the comments about reservations?
> 
> If there are reasons not to do that, I'm not opposed to this patch
> as-is.

I agree, it would be better to merge them.

My concern was that the correct way to get these definitions from
userspace is very unclear, so there may be software out there
including  directly, which would now lack expected
definitions.

codesearch.debian.net shows no real hits for that, so maybe I'm too
paranoid.

Since  only contains #defines, it may be enough for arch
 headers to include .

Thoughts?

Cheers
---Dave


Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Dave Martin
On Wed, May 16, 2018 at 11:29:13AM -0400, Rich Felker wrote:
> On Wed, May 16, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> > There are constraints on defining AT_* auxvec tags that are not
> > obvious to the casual maintainer of either the global
> >  or the arch-specific headers.  This is likely
> > to lead to mistakes.  (I certainly fell foul of it...)
> > 
> > For the benefit of future maintainers, this patch collects the
> > relevant information in one place, documenting how the namespace
> > needs to be managed, and noting all the values currently in use.
> > 
> > Maintaining a global list may result in some merge conflicts, but
> > AT_* values are not added frequently.  I'm open to suggestions on
> > the best approach.
> > 
> > I also assume that values 38 and 39 may have been used for
> > historical purposes, such as an architecture that is no longer
> > supported.  If they have definitely never been used for anything,
> > they could be removed from the "reserved" list.
> 
> On the userspace side (elf.h) all the AT_* constants are in one file.
> Why don't we just do the same here and eliminate the
> arch/*/include/uapi/asm/auxvec.h files and likewise the need to
> manually maintain consistency of the comments about reservations?
> 
> If there are reasons not to do that, I'm not opposed to this patch
> as-is.

I agree, it would be better to merge them.

My concern was that the correct way to get these definitions from
userspace is very unclear, so there may be software out there
including  directly, which would now lack expected
definitions.

codesearch.debian.net shows no real hits for that, so maybe I'm too
paranoid.

Since  only contains #defines, it may be enough for arch
 headers to include .

Thoughts?

Cheers
---Dave


Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Rich Felker
On Wed, May 16, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> There are constraints on defining AT_* auxvec tags that are not
> obvious to the casual maintainer of either the global
>  or the arch-specific headers.  This is likely
> to lead to mistakes.  (I certainly fell foul of it...)
> 
> For the benefit of future maintainers, this patch collects the
> relevant information in one place, documenting how the namespace
> needs to be managed, and noting all the values currently in use.
> 
> Maintaining a global list may result in some merge conflicts, but
> AT_* values are not added frequently.  I'm open to suggestions on
> the best approach.
> 
> I also assume that values 38 and 39 may have been used for
> historical purposes, such as an architecture that is no longer
> supported.  If they have definitely never been used for anything,
> they could be removed from the "reserved" list.

On the userspace side (elf.h) all the AT_* constants are in one file.
Why don't we just do the same here and eliminate the
arch/*/include/uapi/asm/auxvec.h files and likewise the need to
manually maintain consistency of the comments about reservations?

If there are reasons not to do that, I'm not opposed to this patch
as-is.

Rich


Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Rich Felker
On Wed, May 16, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> There are constraints on defining AT_* auxvec tags that are not
> obvious to the casual maintainer of either the global
>  or the arch-specific headers.  This is likely
> to lead to mistakes.  (I certainly fell foul of it...)
> 
> For the benefit of future maintainers, this patch collects the
> relevant information in one place, documenting how the namespace
> needs to be managed, and noting all the values currently in use.
> 
> Maintaining a global list may result in some merge conflicts, but
> AT_* values are not added frequently.  I'm open to suggestions on
> the best approach.
> 
> I also assume that values 38 and 39 may have been used for
> historical purposes, such as an architecture that is no longer
> supported.  If they have definitely never been used for anything,
> they could be removed from the "reserved" list.

On the userspace side (elf.h) all the AT_* constants are in one file.
Why don't we just do the same here and eliminate the
arch/*/include/uapi/asm/auxvec.h files and likewise the need to
manually maintain consistency of the comments about reservations?

If there are reasons not to do that, I'm not opposed to this patch
as-is.

Rich


[RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Dave Martin
There are constraints on defining AT_* auxvec tags that are not
obvious to the casual maintainer of either the global
 or the arch-specific headers.  This is likely
to lead to mistakes.  (I certainly fell foul of it...)

For the benefit of future maintainers, this patch collects the
relevant information in one place, documenting how the namespace
needs to be managed, and noting all the values currently in use.

Maintaining a global list may result in some merge conflicts, but
AT_* values are not added frequently.  I'm open to suggestions on
the best approach.

I also assume that values 38 and 39 may have been used for
historical purposes, such as an architecture that is no longer
supported.  If they have definitely never been used for anything,
they could be removed from the "reserved" list.

Signed-off-by: Dave Martin 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Chris Zankel 
Cc: Max Filippov 
---
 arch/alpha/include/uapi/asm/auxvec.h  |  5 
 arch/arm/include/uapi/asm/auxvec.h|  5 
 arch/arm64/include/uapi/asm/auxvec.h  |  5 
 arch/ia64/include/uapi/asm/auxvec.h   |  5 
 arch/microblaze/include/uapi/asm/auxvec.h |  4 
 arch/mips/include/uapi/asm/auxvec.h   |  5 
 arch/nds32/include/uapi/asm/auxvec.h  |  5 
 arch/powerpc/include/uapi/asm/auxvec.h|  5 
 arch/riscv/include/uapi/asm/auxvec.h  |  5 
 arch/s390/include/uapi/asm/auxvec.h   |  5 
 arch/sh/include/uapi/asm/auxvec.h |  5 
 arch/sparc/include/uapi/asm/auxvec.h  |  8 ---
 arch/x86/include/uapi/asm/auxvec.h|  5 
 arch/xtensa/include/uapi/asm/auxvec.h |  5 
 include/uapi/linux/auxvec.h   | 40 ---
 15 files changed, 106 insertions(+), 6 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/auxvec.h 
b/arch/alpha/include/uapi/asm/auxvec.h
index 57cae87..9370d78 100644
--- a/arch/alpha/include/uapi/asm/auxvec.h
+++ b/arch/alpha/include/uapi/asm/auxvec.h
@@ -22,6 +22,11 @@
 #define AT_L2_CACHESHAPE   36
 #define AT_L3_CACHESHAPE   37
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #define AT_VECTOR_SIZE_ARCH 4 /* entries in ARCH_DLINFO */
 
 #endif /* __ASM_ALPHA_AUXVEC_H */
diff --git a/arch/arm/include/uapi/asm/auxvec.h 
b/arch/arm/include/uapi/asm/auxvec.h
index 5c09da5..b5cfba2 100644
--- a/arch/arm/include/uapi/asm/auxvec.h
+++ b/arch/arm/include/uapi/asm/auxvec.h
@@ -5,4 +5,9 @@
 /* VDSO location */
 #define AT_SYSINFO_EHDR33
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #endif
diff --git a/arch/arm64/include/uapi/asm/auxvec.h 
b/arch/arm64/include/uapi/asm/auxvec.h
index ec0a86d..3da03fc 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -20,6 +20,11 @@
 /* vDSO location */
 #define AT_SYSINFO_EHDR33
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
 
 #endif
diff --git a/arch/ia64/include/uapi/asm/auxvec.h 
b/arch/ia64/include/uapi/asm/auxvec.h
index 09969a5..a81aec5 100644
--- a/arch/ia64/include/uapi/asm/auxvec.h
+++ b/arch/ia64/include/uapi/asm/auxvec.h
@@ -9,6 +9,11 @@
 #define AT_SYSINFO 32
 #define AT_SYSINFO_EHDR33
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
 
 #endif /* _ASM_IA64_AUXVEC_H */
diff --git a/arch/microblaze/include/uapi/asm/auxvec.h 
b/arch/microblaze/include/uapi/asm/auxvec.h
index 93dd07b..b08c6dc 100644
--- a/arch/microblaze/include/uapi/asm/auxvec.h
+++ b/arch/microblaze/include/uapi/asm/auxvec.h
@@ -1,2 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
diff 

[RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

2018-05-16 Thread Dave Martin
There are constraints on defining AT_* auxvec tags that are not
obvious to the casual maintainer of either the global
 or the arch-specific headers.  This is likely
to lead to mistakes.  (I certainly fell foul of it...)

For the benefit of future maintainers, this patch collects the
relevant information in one place, documenting how the namespace
needs to be managed, and noting all the values currently in use.

Maintaining a global list may result in some merge conflicts, but
AT_* values are not added frequently.  I'm open to suggestions on
the best approach.

I also assume that values 38 and 39 may have been used for
historical purposes, such as an architecture that is no longer
supported.  If they have definitely never been used for anything,
they could be removed from the "reserved" list.

Signed-off-by: Dave Martin 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Chris Zankel 
Cc: Max Filippov 
---
 arch/alpha/include/uapi/asm/auxvec.h  |  5 
 arch/arm/include/uapi/asm/auxvec.h|  5 
 arch/arm64/include/uapi/asm/auxvec.h  |  5 
 arch/ia64/include/uapi/asm/auxvec.h   |  5 
 arch/microblaze/include/uapi/asm/auxvec.h |  4 
 arch/mips/include/uapi/asm/auxvec.h   |  5 
 arch/nds32/include/uapi/asm/auxvec.h  |  5 
 arch/powerpc/include/uapi/asm/auxvec.h|  5 
 arch/riscv/include/uapi/asm/auxvec.h  |  5 
 arch/s390/include/uapi/asm/auxvec.h   |  5 
 arch/sh/include/uapi/asm/auxvec.h |  5 
 arch/sparc/include/uapi/asm/auxvec.h  |  8 ---
 arch/x86/include/uapi/asm/auxvec.h|  5 
 arch/xtensa/include/uapi/asm/auxvec.h |  5 
 include/uapi/linux/auxvec.h   | 40 ---
 15 files changed, 106 insertions(+), 6 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/auxvec.h 
b/arch/alpha/include/uapi/asm/auxvec.h
index 57cae87..9370d78 100644
--- a/arch/alpha/include/uapi/asm/auxvec.h
+++ b/arch/alpha/include/uapi/asm/auxvec.h
@@ -22,6 +22,11 @@
 #define AT_L2_CACHESHAPE   36
 #define AT_L3_CACHESHAPE   37
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #define AT_VECTOR_SIZE_ARCH 4 /* entries in ARCH_DLINFO */
 
 #endif /* __ASM_ALPHA_AUXVEC_H */
diff --git a/arch/arm/include/uapi/asm/auxvec.h 
b/arch/arm/include/uapi/asm/auxvec.h
index 5c09da5..b5cfba2 100644
--- a/arch/arm/include/uapi/asm/auxvec.h
+++ b/arch/arm/include/uapi/asm/auxvec.h
@@ -5,4 +5,9 @@
 /* VDSO location */
 #define AT_SYSINFO_EHDR33
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #endif
diff --git a/arch/arm64/include/uapi/asm/auxvec.h 
b/arch/arm64/include/uapi/asm/auxvec.h
index ec0a86d..3da03fc 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -20,6 +20,11 @@
 /* vDSO location */
 #define AT_SYSINFO_EHDR33
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
 
 #endif
diff --git a/arch/ia64/include/uapi/asm/auxvec.h 
b/arch/ia64/include/uapi/asm/auxvec.h
index 09969a5..a81aec5 100644
--- a/arch/ia64/include/uapi/asm/auxvec.h
+++ b/arch/ia64/include/uapi/asm/auxvec.h
@@ -9,6 +9,11 @@
 #define AT_SYSINFO 32
 #define AT_SYSINFO_EHDR33
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
 
 #endif /* _ASM_IA64_AUXVEC_H */
diff --git a/arch/microblaze/include/uapi/asm/auxvec.h 
b/arch/microblaze/include/uapi/asm/auxvec.h
index 93dd07b..b08c6dc 100644
--- a/arch/microblaze/include/uapi/asm/auxvec.h
+++ b/arch/microblaze/include/uapi/asm/auxvec.h
@@ -1,2 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
diff --git a/arch/mips/include/uapi/asm/auxvec.h 
b/arch/mips/include/uapi/asm/auxvec.h
index 612c2c4..ee94899 100644
--- a/arch/mips/include/uapi/asm/auxvec.h
+++ b/arch/mips/include/uapi/asm/auxvec.h
@@ -15,6 +15,11 @@
 /* Location of VDSO image. */
 #define AT_SYSINFO_EHDR33
 
+/*
+ * Do not add new AT_* definitions here without coordinating with
+ * 
+ */
+
 #define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
 
 #endif /* __ASM_AUXVEC_H */
diff --git a/arch/nds32/include/uapi/asm/auxvec.h 
b/arch/nds32/include/uapi/asm/auxvec.h
index 56043ce..0173da1 100644
---