linux-kernel - Re: [PATCH v4 0/4] openat2: new OPENAT2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFfO_h4Hw5Lu-PQn4C31Cdzcz2AH5zmWa-TB8ocdci5K=F8m7Q@mail.gmail.com>
Date: Wed, 11 Feb 2026 22:05:28 +0600
From: Dorjoy Chowdhury <dorjoychy111@...il.com>
To: linux-fsdevel@...r.kernel.org, brauner@...nel.org, jlayton@...nel.org
Cc: linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk, jack@...e.cz, 
	chuck.lever@...cle.com, alex.aring@...il.com, arnd@...db.de, 
	adilger@...ger.ca, mjguzik@...il.com, smfrench@...il.com
Subject: Re: [PATCH v4 0/4] openat2: new OPENAT2_REGULAR flag support

On Sat, Feb 7, 2026 at 1:05 AM Dorjoy Chowdhury <dorjoychy111@...il.com> 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@gmail.com/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@gmail.com/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@gmail.com/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