The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [RFC PATCH v4 0/2] vfs: add O_CREAT|O_DIRECTORY to open*(2)
@ 2026-05-18 16:52 Jori Koolstra
  2026-05-18 16:52 ` [RFC PATCH v4 1/2] " Jori Koolstra
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Jori Koolstra @ 2026-05-18 16:52 UTC (permalink / raw)
  To: Alexander Viro, Christian Brauner, Jan Kara, Aleksa Sarai
  Cc: Jori Koolstra, linux-kernel, linux-fsdevel, cmirabil,
	Jori Koolstra

This series implements new semantics for the O_CREAT|O_DIRECTORY flag
combination for open*(2): perform a mkdir and open the resulting
directory; return a pinning fd (which mkdir does not).

Feedback by Christian Brauner and Aleksa Sarai on the v2 rfc of this
patch was to not introduce a new syscall (mkdirat2) but implement this
functionality as O_CREAT|O_DIRECTORY in open*(2). I had some very silly
bugs that syzbot alerted me of in v3, so here is v4...

Three comments from me upfront:

- This patch just EINVAL bans O_CREAT|O_DIRECTORY for filesystems that
  define atomic_open(). I figure it is better to (dis)allow on a fs per
  fs basis. So feedback per filesystem on what is the appropriate course
  of action on receiving O_CREAT|O_DIRECTORY would be very welcome.

- If we create a regular file with mknod, before creation
  security_path_mknod() is called, and after creation
  security_path_post_mknod(). If we create a regular file using O_CREAT
  (and this is also pre-patch) only security_path_mknod() is called. Is
  this the correct behaviour?

- open_last_lookups() locks the parent inode like like: 

		inode_lock(dir->d_inode);

  should this perhaps be

		inode_lock_nested(dir, I_MUTEX_PARENT);

  to stay consistent with the start_dirop() path that is used by
  filename_create() for instance in mknod(2)? I get that we are only
  locking one inode here at most, so it does not really matter, but
  now one regular file create path does set the lockdep and the other
  does not.

Jori Koolstra (2):
  vfs: add O_CREAT|O_DIRECTORY to open*(2)
  selftest: add tests for open*(O_CREAT|O_DIRECTORY)

 fs/namei.c                                    | 180 +++++++++++-----
 fs/open.c                                     |  25 ++-
 include/uapi/asm-generic/fcntl.h              |   2 +
 .../testing/selftests/filesystems/.gitignore  |   1 +
 tools/testing/selftests/filesystems/Makefile  |   4 +-
 tools/testing/selftests/filesystems/fclog.c   |   1 +
 .../filesystems/open_o_creat_o_dir.c          | 200 ++++++++++++++++++
 7 files changed, 342 insertions(+), 71 deletions(-)
 create mode 100644 tools/testing/selftests/filesystems/open_o_creat_o_dir.c

-- 
2.54.0


^ permalink raw reply	[flat|nested] 9+ messages in thread
* [RFC PATCH v3 0/2] vfs: add O_CREAT|O_DIRECTORY to open*(2)
@ 2026-05-17 17:02 Jori Koolstra
  2026-05-18  7:28 ` [syzbot ci] " syzbot ci
  0 siblings, 1 reply; 9+ messages in thread
From: Jori Koolstra @ 2026-05-17 17:02 UTC (permalink / raw)
  To: Alexander Viro, Christian Brauner, Jan Kara, Aleksa Sarai
  Cc: Jori Koolstra, linux-kernel, linux-fsdevel, cmirabil

This series implements new semantics for the O_CREAT|O_DIRECTORY flag
combination for open*(2): perform a mkdir and open the resulting
directory, and return a pinning fd (which mkdir does not).

Feedback on the v2 rfc of this patch was to not introduce a new syscall
(mkdirat2) but implement this functionality as O_CREAT|O_DIRECTORY in
open*(2).

Two comments from me upfront:

- This patch just EINVAL bans O_CREAT|O_DIRECTORY for filesystems that
  define atomic_open(). I figure it is better to (dis)allow on a fs per
  fs basis. So feedback per filesystem on what is the appropriate course
  of action on receiving O_CREAT|O_DIRECTORY would be very useful.
- If we create a regular file with mknod, before creation
  security_path_mknod() is called, and after creation
  security_path_post_mknod(). If we create a regular file using O_CREAT
  (and this is also pre-patch) only security_path_mknod() is called. Is
  this the correct behaviour?

Jori Koolstra (2):
  vfs: add O_CREAT|O_DIRECTORY to open*(2)
  selftest: add tests for open*(O_CREAT|O_DIRECTORY)

 fs/namei.c                                    | 186 +++++++++++-------
 fs/open.c                                     |  23 +--
 include/uapi/asm-generic/fcntl.h              |   2 +
 .../testing/selftests/filesystems/.gitignore  |   1 +
 tools/testing/selftests/filesystems/Makefile  |   4 +-
 tools/testing/selftests/filesystems/fclog.c   |   1 +
 .../filesystems/open_o_creat_o_directory.c    | 147 ++++++++++++++
 7 files changed, 283 insertions(+), 81 deletions(-)
 create mode 100644 tools/testing/selftests/filesystems/open_o_creat_o_directory.c

-- 
2.54.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2026-05-25 19:02 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-18 16:52 [RFC PATCH v4 0/2] vfs: add O_CREAT|O_DIRECTORY to open*(2) Jori Koolstra
2026-05-18 16:52 ` [RFC PATCH v4 1/2] " Jori Koolstra
2026-05-18 16:52 ` [RFC PATCH v4 2/2] selftest: add tests for open*(O_CREAT|O_DIRECTORY) Jori Koolstra
2026-05-19  6:59 ` [syzbot ci] Re: vfs: add O_CREAT|O_DIRECTORY to open*(2) syzbot ci
2026-05-25 10:35   ` Jori Koolstra
2026-05-25 11:39     ` syzbot ci
2026-05-25 18:30   ` Jori Koolstra
2026-05-25 19:02     ` syzbot ci
  -- strict thread matches above, loose matches on Subject: below --
2026-05-17 17:02 [RFC PATCH v3 0/2] " Jori Koolstra
2026-05-18  7:28 ` [syzbot ci] " syzbot ci

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox