> Op 16-04-2026 16:21 CEST schreef Dorjoy Chowdhury <[email protected]>: > > > On Thu, Apr 16, 2026 at 7:52 PM Jori Koolstra <[email protected]> wrote: > > > > On Sat, Mar 28, 2026 at 11:22:22PM +0600, Dorjoy Chowdhury wrote: > > > diff --git a/arch/alpha/include/uapi/asm/fcntl.h > > > b/arch/alpha/include/uapi/asm/fcntl.h > > > index 50bdc8e8a271..fe488bf7c18e 100644 > > > --- a/arch/alpha/include/uapi/asm/fcntl.h > > > +++ b/arch/alpha/include/uapi/asm/fcntl.h > > > @@ -34,6 +34,7 @@ > > > > > > #define O_PATH 040000000 > > > #define __O_TMPFILE 0100000000 > > > +#define OPENAT2_REGULAR 0200000000 > > > > > > > I don't quite understand why we are adding OPENAT2_REGULAR inside the > > O_* flag range. Wasn't this supposed to be only supported for openat2()? > > If so, I don't see the need to waste an O_* flag bit. But maybe I am > > missing something. > > > > Yes, OPENAT2_REGULAR is only supported for openat2. I am not sure if I > got a specific review to not add OPENAT2_REGULAR in the O_* flag 32 > bit range. But as far as I understand, for the old open system calls > we can't easily add new O_* flags as the older codepaths don't strip > off unknown bits which openat2 does. It's not easy to add new O_* > flags for the old open system calls since that could break userspace > programs.
If I recall correctly, Aleksa has suggested we might also want to add O_EMPTYPATH to openat() instead of only allowing this for openat2(). I am waiting to see what Christian thinks of this. I guess in that case it is relatively harmless to change UAPI behavior because openat() with an empty path never works; so it would be silly if there are userspace programs that make this call, which always fails and does nothing, and somehow rely on that. > So I guess it's okay to add OPENAT2_REGULAR in the 32 bits > range anyway? (Also lots of code paths take 32bit flags param right > now and those would need changing to take uint64_t instead but this is > of course not a reason to not add the new flag outside of the 32 > bits). > > Regards, > Dorjoy Thanks, Jori.
