Re: [PATCH v6 0/4] OPENAT2_REGULAR flag support for openat2

Christian Brauner <[email protected]> Thu, 21 May 2026 12:53:56 +0200
Newsgroups dev.linux.lists.gfs2,dev.linux.lists.v9fs,org.kernel.vger.ceph-devel,org.kernel.vger.linux-api,org.kernel.vger.linux-cifs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-nfs
Message-ID <20260521-grube-leitfaden-0e5420c9bedc@brauner>
On Thu, Apr 16, 2026 at 03:07:12PM +0200, Christian Brauner wrote:
> On Sat, 28 Mar 2026 23:22:21 +0600, Dorjoy Chowdhury wrote:
> > 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.
> > 
> > The following filesystems have been tested by building and booting the kernel
> > x86 bzImage in a Fedora 43 VM in QEMU. I have tested with OPENAT2_REGULAR that
> > regular files can be successfully opened and non-regular files (directory, fifo etc)
> > return -EFTYPE.
> > - btrfs
> > - NFS (loopback)
> > - SMB (loopback)
> > 
> > [...]
> 
> - I've added an explanation why OPENAT2_REGULAR is only needed for some
>   ->atomic_open() implementers but not others. What I don't like is that
>   we need all that custom handling in there but it's managable.
> 
> - I dropped the topmost style conversions. They really don't belong
>   there and if we switch to something better we should use (1 << <nr>).
> 
> - I split the EFTYPE errno introduction into a separate patch.

So I've massaged this series a bit in that I moved OPENAT2_REGULAR into
the upper 64-bit and internally use a __O_REGULAR bit. After having
thought about it makes a lot more sense to move the openat2() only
features into the upper 32-bit for the uapi space. I also ported the
selftests to the TEST* framework to fit with Aleksa's recent rework.