[PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Randy Dunlap]

Don't define the AT_RENAME_* macros at all since the kernel does not
use them nor does the kernel need to provide them for userspace.
Leave them as comments in <uapi/linux/fcntl.h> only as an example.

The AT_RENAME_* macros have recently been added to glibc's <stdio.h>.
For a kernel allmodconfig build, this made the macros be defined
differently in 2 places (same values but different macro text),
causing build errors/warnings (duplicate definitions) in both
samples/watch_queue/watch_test.c and samples/vfs/test-statx.c.
(<linux/fcntl.h> is included indirecty in both programs above.)

Fixes: b4fef22c2fb9 ("uapi: explain how per-syscall AT_* flags should be allocated")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Amir Goldstein <amir73il@gmail.com>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: David Howells <dhowells@redhat.com>
CC: linux-api@vger.kernel.org
To: linux-fsdevel@vger.kernel.org
---
 include/uapi/linux/fcntl.h |    6 ++++++
 1 file changed, 6 insertions(+)

--- linux-next-20250819.orig/include/uapi/linux/fcntl.h
+++ linux-next-20250819/include/uapi/linux/fcntl.h
@@ -155,10 +155,16 @@
  * as possible, so we can use them for generic bits in the future if necessary.
  */
 
+/*
+ * Note: This is an example of how the AT_RENAME_* flags could be defined,
+ * but the kernel has no need to define them, so leave them as comments.
+ */
 /* Flags for renameat2(2) (must match legacy RENAME_* flags). */
+/*
 #define AT_RENAME_NOREPLACE	0x0001
 #define AT_RENAME_EXCHANGE	0x0002
 #define AT_RENAME_WHITEOUT	0x0004
+*/
 
 /* Flag for faccessat(2). */
 #define AT_EACCESS		0x200	/* Test access permitted for

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Amir Goldstein]

On Thu, Sep 4, 2025 at 8:22 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Don't define the AT_RENAME_* macros at all since the kernel does not
> use them nor does the kernel need to provide them for userspace.
> Leave them as comments in <uapi/linux/fcntl.h> only as an example.
>
> The AT_RENAME_* macros have recently been added to glibc's <stdio.h>.
> For a kernel allmodconfig build, this made the macros be defined
> differently in 2 places (same values but different macro text),
> causing build errors/warnings (duplicate definitions) in both
> samples/watch_queue/watch_test.c and samples/vfs/test-statx.c.
> (<linux/fcntl.h> is included indirecty in both programs above.)
>
> Fixes: b4fef22c2fb9 ("uapi: explain how per-syscall AT_* flags should be allocated")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Amir Goldstein <amir73il@gmail.com>
> Cc: Jeff Layton <jlayton@kernel.org>
> Cc: Chuck Lever <chuck.lever@oracle.com>
> Cc: Alexander Aring <alex.aring@gmail.com>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: Aleksa Sarai <cyphar@cyphar.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: David Howells <dhowells@redhat.com>
> CC: linux-api@vger.kernel.org
> To: linux-fsdevel@vger.kernel.org
> ---
>  include/uapi/linux/fcntl.h |    6 ++++++
>  1 file changed, 6 insertions(+)
>
> --- linux-next-20250819.orig/include/uapi/linux/fcntl.h
> +++ linux-next-20250819/include/uapi/linux/fcntl.h
> @@ -155,10 +155,16 @@
>   * as possible, so we can use them for generic bits in the future if necessary.
>   */
>
> +/*
> + * Note: This is an example of how the AT_RENAME_* flags could be defined,
> + * but the kernel has no need to define them, so leave them as comments.
> + */
>  /* Flags for renameat2(2) (must match legacy RENAME_* flags). */
> +/*
>  #define AT_RENAME_NOREPLACE    0x0001
>  #define AT_RENAME_EXCHANGE     0x0002
>  #define AT_RENAME_WHITEOUT     0x0004
> +*/
>

I find this end result a bit odd, but I don't want to suggest another variant
I already proposed one in v2 review [1] that maybe you did not like.
It's fine.
I'll let Aleksa and Christian chime in to decide on if and how they want this
comment to look or if we should just delete these definitions and be done with
this episode.

Thanks,
Amir.

[1] https://lore.kernel.org/r/CAOQ4uxjXvYBsW1Nb2HKaoUg1qi8Pkq1XKtQEbnAvMUGcp7LrZA@mail.gmail.com/

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Florian Weimer]

* Amir Goldstein:

> I find this end result a bit odd, but I don't want to suggest another variant
> I already proposed one in v2 review [1] that maybe you did not like.
> It's fine.
> I'll let Aleksa and Christian chime in to decide on if and how they want this
> comment to look or if we should just delete these definitions and be done with
> this episode.

We should fix the definition in glibc to be identical token-wise to the
kernel's.

Thanks,
Florian

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Randy Dunlap]

On 9/4/25 11:49 AM, Florian Weimer wrote:
> * Amir Goldstein:
> 
>> I find this end result a bit odd, but I don't want to suggest another variant
>> I already proposed one in v2 review [1] that maybe you did not like.
>> It's fine.
>> I'll let Aleksa and Christian chime in to decide on if and how they want this
>> comment to look or if we should just delete these definitions and be done with
>> this episode.
> 
> We should fix the definition in glibc to be identical token-wise to the
> kernel's.

That's probably a good suggestion...
while I tried the reverse of that and Amir opposed.

Now I find that I don't care enough to sustain this.

Thanks.

-- 
~Randy

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Florian Weimer]

* Randy Dunlap:

> On 9/4/25 11:49 AM, Florian Weimer wrote:
>> * Amir Goldstein:
>> 
>>> I find this end result a bit odd, but I don't want to suggest another variant
>>> I already proposed one in v2 review [1] that maybe you did not like.
>>> It's fine.
>>> I'll let Aleksa and Christian chime in to decide on if and how they want this
>>> comment to look or if we should just delete these definitions and be done with
>>> this episode.
>> 
>> We should fix the definition in glibc to be identical token-wise to the
>> kernel's.
>
> That's probably a good suggestion...
> while I tried the reverse of that and Amir opposed.

It's certainly odd that the kernel uses different token sequences for
defining AT_RENAME_* and RENAME_*.  But it's probably too late to fix
that.

Here's the glibc patch:

  [PATCH] libio: Define AT_RENAME_* with the same tokens as Linux
  <https://inbox.sourceware.org/libc-alpha/lhubjnpv03o.fsf@oldenburg.str.redhat.com/T/#u>

Thanks,
Florian

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Randy Dunlap]

Hi,

On 9/5/25 12:19 AM, Florian Weimer wrote:
> * Randy Dunlap:
> 
>> On 9/4/25 11:49 AM, Florian Weimer wrote:
>>> * Amir Goldstein:
>>>
>>>> I find this end result a bit odd, but I don't want to suggest another variant
>>>> I already proposed one in v2 review [1] that maybe you did not like.
>>>> It's fine.
>>>> I'll let Aleksa and Christian chime in to decide on if and how they want this
>>>> comment to look or if we should just delete these definitions and be done with
>>>> this episode.
>>>
>>> We should fix the definition in glibc to be identical token-wise to the
>>> kernel's.
>>
>> That's probably a good suggestion...
>> while I tried the reverse of that and Amir opposed.
> 
> It's certainly odd that the kernel uses different token sequences for
> defining AT_RENAME_* and RENAME_*.  But it's probably too late to fix
> that.
> 
> Here's the glibc patch:
> 
>   [PATCH] libio: Define AT_RENAME_* with the same tokens as Linux
>   <https://inbox.sourceware.org/libc-alpha/lhubjnpv03o.fsf@oldenburg.str.redhat.com/T/#u>


Thanks!

-- 
~Randy

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Randy Dunlap]

On 9/4/25 11:17 AM, Amir Goldstein wrote:
> On Thu, Sep 4, 2025 at 8:22 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> Don't define the AT_RENAME_* macros at all since the kernel does not
>> use them nor does the kernel need to provide them for userspace.
>> Leave them as comments in <uapi/linux/fcntl.h> only as an example.
>>
>> The AT_RENAME_* macros have recently been added to glibc's <stdio.h>.
>> For a kernel allmodconfig build, this made the macros be defined
>> differently in 2 places (same values but different macro text),
>> causing build errors/warnings (duplicate definitions) in both
>> samples/watch_queue/watch_test.c and samples/vfs/test-statx.c.
>> (<linux/fcntl.h> is included indirecty in both programs above.)
>>
>> Fixes: b4fef22c2fb9 ("uapi: explain how per-syscall AT_* flags should be allocated")
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>> Cc: Amir Goldstein <amir73il@gmail.com>
>> Cc: Jeff Layton <jlayton@kernel.org>
>> Cc: Chuck Lever <chuck.lever@oracle.com>
>> Cc: Alexander Aring <alex.aring@gmail.com>
>> Cc: Josef Bacik <josef@toxicpanda.com>
>> Cc: Aleksa Sarai <cyphar@cyphar.com>
>> Cc: Jan Kara <jack@suse.cz>
>> Cc: Christian Brauner <brauner@kernel.org>
>> Cc: Matthew Wilcox <willy@infradead.org>
>> Cc: David Howells <dhowells@redhat.com>
>> CC: linux-api@vger.kernel.org
>> To: linux-fsdevel@vger.kernel.org
>> ---
>>  include/uapi/linux/fcntl.h |    6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> --- linux-next-20250819.orig/include/uapi/linux/fcntl.h
>> +++ linux-next-20250819/include/uapi/linux/fcntl.h
>> @@ -155,10 +155,16 @@
>>   * as possible, so we can use them for generic bits in the future if necessary.
>>   */
>>
>> +/*
>> + * Note: This is an example of how the AT_RENAME_* flags could be defined,
>> + * but the kernel has no need to define them, so leave them as comments.
>> + */
>>  /* Flags for renameat2(2) (must match legacy RENAME_* flags). */
>> +/*
>>  #define AT_RENAME_NOREPLACE    0x0001
>>  #define AT_RENAME_EXCHANGE     0x0002
>>  #define AT_RENAME_WHITEOUT     0x0004
>> +*/
>>
> 
> I find this end result a bit odd, but I don't want to suggest another variant
> I already proposed one in v2 review [1] that maybe you did not like.
> It's fine.

Yes, I replied to that with another problem.

> I'll let Aleksa and Christian chime in to decide on if and how they want this
> comment to look or if we should just delete these definitions and be done with
> this episode.

Sure, I'm ready to just throw my hands up (give up).

> 
> Thanks,
> Amir.
> 
> [1] https://lore.kernel.org/r/CAOQ4uxjXvYBsW1Nb2HKaoUg1qi8Pkq1XKtQEbnAvMUGcp7LrZA@mail.gmail.com/
thanks.
-- 
~Randy

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

On 2025-09-04, Amir Goldstein <amir73il@gmail.com> wrote:
> On Thu, Sep 4, 2025 at 8:22 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> >
> > Don't define the AT_RENAME_* macros at all since the kernel does not
> > use them nor does the kernel need to provide them for userspace.
> > Leave them as comments in <uapi/linux/fcntl.h> only as an example.
> >
> > The AT_RENAME_* macros have recently been added to glibc's <stdio.h>.
> > For a kernel allmodconfig build, this made the macros be defined
> > differently in 2 places (same values but different macro text),
> > causing build errors/warnings (duplicate definitions) in both
> > samples/watch_queue/watch_test.c and samples/vfs/test-statx.c.
> > (<linux/fcntl.h> is included indirecty in both programs above.)
> >
> > Fixes: b4fef22c2fb9 ("uapi: explain how per-syscall AT_* flags should be allocated")
> > Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > ---
> > Cc: Amir Goldstein <amir73il@gmail.com>
> > Cc: Jeff Layton <jlayton@kernel.org>
> > Cc: Chuck Lever <chuck.lever@oracle.com>
> > Cc: Alexander Aring <alex.aring@gmail.com>
> > Cc: Josef Bacik <josef@toxicpanda.com>
> > Cc: Aleksa Sarai <cyphar@cyphar.com>
> > Cc: Jan Kara <jack@suse.cz>
> > Cc: Christian Brauner <brauner@kernel.org>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: David Howells <dhowells@redhat.com>
> > CC: linux-api@vger.kernel.org
> > To: linux-fsdevel@vger.kernel.org
> > ---
> >  include/uapi/linux/fcntl.h |    6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > --- linux-next-20250819.orig/include/uapi/linux/fcntl.h
> > +++ linux-next-20250819/include/uapi/linux/fcntl.h
> > @@ -155,10 +155,16 @@
> >   * as possible, so we can use them for generic bits in the future if necessary.
> >   */
> >
> > +/*
> > + * Note: This is an example of how the AT_RENAME_* flags could be defined,
> > + * but the kernel has no need to define them, so leave them as comments.
> > + */
> >  /* Flags for renameat2(2) (must match legacy RENAME_* flags). */
> > +/*
> >  #define AT_RENAME_NOREPLACE    0x0001
> >  #define AT_RENAME_EXCHANGE     0x0002
> >  #define AT_RENAME_WHITEOUT     0x0004
> > +*/
> >
> 
> I find this end result a bit odd, but I don't want to suggest another variant
> I already proposed one in v2 review [1] that maybe you did not like.
> It's fine.
> I'll let Aleksa and Christian chime in to decide on if and how they want this
> comment to look or if we should just delete these definitions and be done with
> this episode.

For my part, I'm fine with these becoming comments or even removing them
outright. I think that defining them as AT_* flags would've been useful
examples of how these flags should be used, but it is what it is.

Then again, AT_EXECVE_CHECK went in and used a higher-level bit despite
the comments describing that this was unfavourable and what should be
done instead, so maybe attempting to avoid conflicts is an exercise in
futility...

If it's too much effort to synchronise them between glibc then it's
better to just close the book on this whole chapter (even though my
impression is that glibc made a mistake or two when adding the
definitions).

In either case, feel free to take my

Acked-by: Aleksa Sarai <cyphar@cyphar.com>

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Amir Goldstein]

On Fri, Sep 5, 2025 at 7:11 AM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> On 2025-09-04, Amir Goldstein <amir73il@gmail.com> wrote:
> > On Thu, Sep 4, 2025 at 8:22 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> > >
> > > Don't define the AT_RENAME_* macros at all since the kernel does not
> > > use them nor does the kernel need to provide them for userspace.
> > > Leave them as comments in <uapi/linux/fcntl.h> only as an example.
> > >
> > > The AT_RENAME_* macros have recently been added to glibc's <stdio.h>.
> > > For a kernel allmodconfig build, this made the macros be defined
> > > differently in 2 places (same values but different macro text),
> > > causing build errors/warnings (duplicate definitions) in both
> > > samples/watch_queue/watch_test.c and samples/vfs/test-statx.c.
> > > (<linux/fcntl.h> is included indirecty in both programs above.)
> > >
> > > Fixes: b4fef22c2fb9 ("uapi: explain how per-syscall AT_* flags should be allocated")
> > > Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > > ---
> > > Cc: Amir Goldstein <amir73il@gmail.com>
> > > Cc: Jeff Layton <jlayton@kernel.org>
> > > Cc: Chuck Lever <chuck.lever@oracle.com>
> > > Cc: Alexander Aring <alex.aring@gmail.com>
> > > Cc: Josef Bacik <josef@toxicpanda.com>
> > > Cc: Aleksa Sarai <cyphar@cyphar.com>
> > > Cc: Jan Kara <jack@suse.cz>
> > > Cc: Christian Brauner <brauner@kernel.org>
> > > Cc: Matthew Wilcox <willy@infradead.org>
> > > Cc: David Howells <dhowells@redhat.com>
> > > CC: linux-api@vger.kernel.org
> > > To: linux-fsdevel@vger.kernel.org
> > > ---
> > >  include/uapi/linux/fcntl.h |    6 ++++++
> > >  1 file changed, 6 insertions(+)
> > >
> > > --- linux-next-20250819.orig/include/uapi/linux/fcntl.h
> > > +++ linux-next-20250819/include/uapi/linux/fcntl.h
> > > @@ -155,10 +155,16 @@
> > >   * as possible, so we can use them for generic bits in the future if necessary.
> > >   */
> > >
> > > +/*
> > > + * Note: This is an example of how the AT_RENAME_* flags could be defined,
> > > + * but the kernel has no need to define them, so leave them as comments.
> > > + */
> > >  /* Flags for renameat2(2) (must match legacy RENAME_* flags). */
> > > +/*
> > >  #define AT_RENAME_NOREPLACE    0x0001
> > >  #define AT_RENAME_EXCHANGE     0x0002
> > >  #define AT_RENAME_WHITEOUT     0x0004
> > > +*/
> > >
> >
> > I find this end result a bit odd, but I don't want to suggest another variant
> > I already proposed one in v2 review [1] that maybe you did not like.
> > It's fine.
> > I'll let Aleksa and Christian chime in to decide on if and how they want this
> > comment to look or if we should just delete these definitions and be done with
> > this episode.
>
> For my part, I'm fine with these becoming comments or even removing them
> outright. I think that defining them as AT_* flags would've been useful
> examples of how these flags should be used, but it is what it is.
>
> Then again, AT_EXECVE_CHECK went in and used a higher-level bit despite
> the comments describing that this was unfavourable and what should be
> done instead, so maybe attempting to avoid conflicts is an exercise in
> futility...

That's a bummer :-/
but to be fair, AT_EXECVE_CHECK was merged after v23, so I guess
the patch set started way before this comment and got rebased
after the comment was added, so it was easier to miss it.

>
> If it's too much effort to synchronise them between glibc then it's
> better to just close the book on this whole chapter (even though my
> impression is that glibc made a mistake or two when adding the
> definitions).

Considering that glibc has this fix lined up:
https://inbox.sourceware.org/libc-alpha/lhubjnpv03o.fsf@oldenburg.str.redhat.com/

Do we need to do anything at all?

Florian,

I am not that familiar with packaging and distributions of glibc
headers and kernel headers to downstream users.

What are the chances that us removing these definitions from the
current kernel header is going to help any downstream user in the future?

Thanks,
Amir.

Re: [PATCH v3] uapi/linux/fcntl: remove AT_RENAME* macros

[Florian Weimer]

* Amir Goldstein:

>> If it's too much effort to synchronise them between glibc then it's
>> better to just close the book on this whole chapter (even though my
>> impression is that glibc made a mistake or two when adding the
>> definitions).
>
> Considering that glibc has this fix lined up:
> https://inbox.sourceware.org/libc-alpha/lhubjnpv03o.fsf@oldenburg.str.redhat.com/
>
> Do we need to do anything at all?
>
> Florian,
>
> I am not that familiar with packaging and distributions of glibc
> headers and kernel headers to downstream users.

I don't think kernel changes are necessary or desirable at this point.
The glibc change went into glibc 2.42 only, and at this point in time,
all distributions shipping 2.42 (few of them do) are pretty much
guaranteed to pick up fixes from the 2.42 stable release branch
regularly.  So if we get this into glibc 2.43 and backport it to 2.42,
the problem should disappear quite soon from a developer's perspective.

Thanks,
Florian