Re: [PATCH v4 0/4] openat2: new OPENAT2_REGULAR flag support

[Dorjoy Chowdhury]

On Wed, Feb 11, 2026 at 10:05 PM Dorjoy Chowdhury
<dorjoychy111@xxxxxxxxx> wrote:
>
> On Sat, Feb 7, 2026 at 1:05 AM Dorjoy Chowdhury <dorjoychy111@xxxxxxxxx> wrote:
> >
> > Note that in v4, for now, I have returned -EINVAL from the atomic_open codepaths.
> > I do want to make this new flag properly supported and proper api behavior, but
> > last time I could not quite understand what should be done for the atomic_open
> > codepaths. So to have a more concrete discussion, I have included the -EINVAL
> > changes.
> >
> > Changes in v4:
> > - changed O_REGULAR to OPENAT2_REGULAR
> > - OPENAT2_REGULAR does not affect O_PATH
> > - OPENAT2_REGULAR with O_DIRECTORY will open path for both directory or regular file
> > - atomic_open codepaths updated to return -EINVAL when OPENAT2_REGULAR is set
> > - commit message includes the uapi-group URL
> > - v3 is at: https://lore.kernel.org/linux-fsdevel/20260127180109.66691-1-dorjoychy111@xxxxxxxxx/T/
> >
> > Changes in v3:
> > - included motivation about O_REGULAR flag in commit message e.g., programs not wanting to be tricked into opening device nodes
> > - fixed commit message wrongly referencing ENOTREGULAR instead of ENOTREG
> > - fixed the O_REGULAR flag in arch/parisc/include/uapi/asm/fcntl.h from 060000000 to 0100000000
> > - added 2 commits converting arch/{mips,sparc}/include/uapi/asm/fcntl.h O_* macros from hex to octal
> > - v2 is at: https://lore.kernel.org/linux-fsdevel/20260126154156.55723-1-dorjoychy111@xxxxxxxxx/T/
> >
> > Changes in v2:
> > - rename ENOTREGULAR to ENOTREG
> > - define ENOTREG in uapi/asm-generic/errno.h (instead of errno-base.h) and in arch/*/include/uapi/asm/errno.h files
> > - override O_REGULAR in arch/{alpha,sparc,parisc}/include/uapi/asm/fcntl.h due to clash with include/uapi/asm-generic/fcntl.h
> > - I have kept the kselftest but now that O_REGULAR and ENOTREG can have different value on different architectures I am not sure if it's right
> > - v1 is at: https://lore.kernel.org/linux-fsdevel/20260125141518.59493-1-dorjoychy111@xxxxxxxxx/T/
> >
> > Hi,
> >
> > I came upon this "Ability to only open regular files" uapi feature suggestion
> > from https://uapi-group.org/kernel-features/#ability-to-only-open-regular-files
> > and thought it would be something I could do as a first patch and get to
> > know the kernel code a bit better.
> >
> > I am not quite sure if the semantics that I baked into the code for this
> > O_REGULAR flag's behavior when combined with other flags like O_CREAT look
> > good and if there are other places that need the checks. I can fixup my
> > patch according to suggestions for improvement. I did some happy path testing
> > and the O_REGULAR flag seems to work as intended.
> >
> > Thanks.
> >
> > Regards,
> > Dorjoy
> >
> > Dorjoy Chowdhury (4):
> >   openat2: new OPENAT2_REGULAR flag support
> >   kselftest/openat2: test for OPENAT2_REGULAR flag
> >   sparc/fcntl.h: convert O_* flag macros from hex to octal
> >   mips/fcntl.h: convert O_* flag macros from hex to octal
> >
> >  arch/alpha/include/uapi/asm/errno.h           |  2 +
> >  arch/alpha/include/uapi/asm/fcntl.h           |  1 +
> >  arch/mips/include/uapi/asm/errno.h            |  2 +
> >  arch/mips/include/uapi/asm/fcntl.h            | 22 ++++-----
> >  arch/parisc/include/uapi/asm/errno.h          |  2 +
> >  arch/parisc/include/uapi/asm/fcntl.h          |  1 +
> >  arch/sparc/include/uapi/asm/errno.h           |  2 +
> >  arch/sparc/include/uapi/asm/fcntl.h           | 35 +++++++-------
> >  fs/9p/vfs_inode.c                             |  3 ++
> >  fs/9p/vfs_inode_dotl.c                        |  3 ++
> >  fs/ceph/file.c                                |  3 ++
> >  fs/fuse/dir.c                                 |  3 ++
> >  fs/gfs2/inode.c                               |  3 ++
> >  fs/namei.c                                    |  9 +++-
> >  fs/nfs/dir.c                                  |  3 ++
> >  fs/nfs/file.c                                 |  3 ++
> >  fs/open.c                                     |  2 +-
> >  fs/smb/client/dir.c                           |  3 ++
> >  fs/vboxsf/dir.c                               |  3 ++
> >  include/linux/fcntl.h                         |  2 +
> >  include/uapi/asm-generic/errno.h              |  2 +
> >  include/uapi/asm-generic/fcntl.h              |  4 ++
> >  tools/arch/alpha/include/uapi/asm/errno.h     |  2 +
> >  tools/arch/mips/include/uapi/asm/errno.h      |  2 +
> >  tools/arch/parisc/include/uapi/asm/errno.h    |  2 +
> >  tools/arch/sparc/include/uapi/asm/errno.h     |  2 +
> >  tools/include/uapi/asm-generic/errno.h        |  2 +
> >  .../testing/selftests/openat2/openat2_test.c  | 46 ++++++++++++++++++-
> >  28 files changed, 138 insertions(+), 31 deletions(-)
> >
> > --
> > 2.53.0
> >
>
> Hi,
> I would appreciate some feedback on this patch series. I think there
> are 2 things that need definite feedback.
>
> 1) I have defined OPENAT2_REGULAR to be in the 32-bit space. At first,
> I tried to make it the 33rd bit but then realized, there are existing
> structs like (struct open_flag and others) where the flag (or similar)
> members are of type int or unsigned int which get passed over to lots
> of places. So I ended up making it a flag in the 32-bit space. I guess
> it's okay as it's not easy to add new flags to existing open syscalls
> due to backward compatibility anyway.
>
> 2) For now, I am returning -EINVAL from the atomic_open codepaths.
> What would be the proper way to handle this? And is there anything
> needed for the file_operations.open codepaths (right now, do_open
> already checks and returns errors for the new flag before we reach
> file_operations.open)? I am a bit confused about the new flag and
> network filesystems where obviously the new flag won't be recognized
> by the server. So, if we want to handle the new flag properly in those
> filesystems, does the flag need to be masked out? It's a bit hard for
> me to understand the right thing that should be done as I am not
> familiar with all the code so I appreciate any help and suggestions on
> this.
>
> Thanks.
>
> Regards,
> Dorjoy

Hi,
Gentle ping for review on this patch series. Thanks!

Regards,
Dorjoy