Re: [PATCH] Add support for empty path in openat and openat2 syscalls

[Christian Brauner]

On Tue, Feb 24, 2026 at 02:35:00PM +0100, Jori Koolstra wrote:
> 
> > Op 24-02-2026 11:10 CET schreef Christian Brauner <brauner@xxxxxxxxxx>:
> > 
> >  
> > On Mon, Feb 23, 2026 at 10:28:24AM -0500, Jeff Layton wrote:
> > > On Mon, 2026-02-23 at 16:16 +0100, Jori Koolstra wrote:
> > > > To get an operable version of an O_PATH file descriptors, it is possible
> > > > to use openat(fd, ".", O_DIRECTORY) for directories, but other files
> > > > currently require going through open("/proc/<pid>/fd/<nr>") which
> > > > depends on a functioning procfs.
> > > > 
> > > > This patch adds the O_EMPTY_PATH flag to openat and openat2. If passed
> > > > LOOKUP_EMPTY is set at path resolve time.
> > > > 
> > > 
> > > This sounds valuable, but there was recent discussion around the
> > > O_REGULAR flag that said that we shouldn't be adding new flags to older
> > > syscalls [1]. Should this only be an OPENAT2_* flag instead?
> > > 
> > > [1]: https://lore.kernel.org/linux-fsdevel/20260129-siebzehn-adler-efe74ff8f1a9@brauner/
> > 
> > I do like restricting it to openat2() as well.
> 
> So would you want to filter the O_EMPTY_PATH flag from openat(), or maybe add
> a RESOLVE_EMPTY flag to the resolve options?

No, add a OPENAT2_EMPTY_PATH in the upper 32 bit of the 64-bit flag
argument for struct open_how. Then it cannot be used in openat(). But
let's wait a day or so to see whether we have someone that really wants
to extend this to openat() as well...