From: David Laight <david.laight.linux@gmail.com>
To: "Arnd Bergmann" <arnd@arndb.de>
Cc: "Jori Koolstra" <jkoolstra@xs4all.nl>,
"Andy Lutomirski" <luto@kernel.org>,
"Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Jeff Layton" <jlayton@kernel.org>,
"Chuck Lever" <chuck.lever@oracle.com>, shuah <shuah@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"H. Peter Anvin" <hpa@zytor.com>, "Jan Kara" <jack@suse.cz>,
"Alexander Aring" <alex.aring@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Oleg Nesterov" <oleg@redhat.com>,
"Andrey Albershteyn" <aalbersh@redhat.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Namhyung Kim" <namhyung@kernel.org>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
"Aleksa Sarai" <cyphar@cyphar.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-kselftest@vger.kernel.org, cmirabil@redhat.com,
"Masami Hiramatsu" <mhiramat@kernel.org>
Subject: Re: [RFC PATCH 1/2] vfs: syscalls: add mkdirat_fd()
Date: Wed, 1 Apr 2026 15:09:22 +0100 [thread overview]
Message-ID: <20260401150922.0990d935@pumpkin> (raw)
In-Reply-To: <c2ea52f2-b232-404b-9ec6-75d8efae6bea@app.fastmail.com>
On Tue, 31 Mar 2026 21:13:34 +0200
"Arnd Bergmann" <arnd@arndb.de> wrote:
> On Tue, Mar 31, 2026, at 19:19, Jori Koolstra wrote:
> > Currently there is no way to race-freely create and open a directory.
> > For regular files we have open(O_CREAT) for creating a new file inode,
> > and returning a pinning fd to it. The lack of such functionality for
> > directories means that when populating a directory tree there's always
> > a race involved: the inodes first need to be created, and then opened
> > to adjust their permissions/ownership/labels/timestamps/acls/xattrs/...,
> > but in the time window between the creation and the opening they might
> > be replaced by something else.
> >
> > Addressing this race without proper APIs is possible (by immediately
> > fstat()ing what was opened, to verify that it has the right inode type),
> > but difficult to get right. Hence, mkdirat_fd() that creates a directory
> > and returns an O_DIRECTORY fd is useful.
> >
> > This feature idea (and description) is taken from the UAPI group:
> > https://github.com/uapi-group/kernel-features?tab=readme-ov-file#race-free-creation-and-opening-of-non-file-inodes
> >
> > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
>
> I checked that the calling conventions are fine, i.e. this will work
> as expected across all architectures. I assume you are also aware
> that the non-RFC patch will need to add the syscall number to all
> .tbl files.
>
> The hardest problem here does seem to be the naming of the
> new syscall, and I'm sorry to not be able to offer any solution
> either, just two observations:
>
> - mkdirat/mkdirat_fd sounds similar to the existing
> quotactl/quotactl_fd pair, but quotactl_fd() takes a file
> descriptor argument rather than returning it, which makes
> this addition quite confusing.
>
> - the nicest interface IMO would have been a variation of
> openat(dfd, filename, O_CREAT | O_DIRECTORY, mode)
> but that is a minefield of incompatible implementations[1],
> so we can't do that without changing the behavior for
> existing callers that currently run into an error.
Just require O_TMPFILE to be set as well :-)
You know you'll never regret it one Apr-1 is over.
Can something be done with the flags to openat2().
That might save allocating an extra system call.
David
>
> Arnd
>
> [1] https://lwn.net/Articles/926782/
>
next prev parent reply other threads:[~2026-04-01 14:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 17:19 [RFC PATCH 0/2] vfs: mkdirat_fd() syscall Jori Koolstra
2026-03-31 17:19 ` [RFC PATCH 1/2] vfs: syscalls: add mkdirat_fd() Jori Koolstra
2026-03-31 19:13 ` Arnd Bergmann
2026-04-01 14:09 ` David Laight [this message]
2026-03-31 20:25 ` Yann Droneaud
2026-03-31 20:42 ` H. Peter Anvin
2026-04-01 4:19 ` Mateusz Guzik
2026-04-01 9:44 ` Cyril Hrubis
2026-04-01 10:25 ` Jori Koolstra
2026-04-07 9:00 ` Mateusz Guzik
2026-04-02 2:52 ` Aleksa Sarai
2026-04-07 8:52 ` Mateusz Guzik
2026-03-31 17:19 ` [RFC PATCH 2/2] selftest: add tests for mkdirat_fd() Jori Koolstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260401150922.0990d935@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=aalbersh@redhat.com \
--cc=acme@redhat.com \
--cc=alex.aring@gmail.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=cmirabil@redhat.com \
--cc=cyphar@cyphar.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jack@suse.cz \
--cc=jkoolstra@xs4all.nl \
--cc=jlayton@kernel.org \
--cc=jolsa@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.org \
--cc=tglx@kernel.org \
--cc=thomas.weissschuh@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox