]> git.ipfire.org Git - thirdparty/linux.git/commit
fs: try an opportunistic lookup for O_CREAT opens too
authorJeff Layton <jlayton@kernel.org>
Wed, 7 Aug 2024 12:10:27 +0000 (08:10 -0400)
committerChristian Brauner <brauner@kernel.org>
Fri, 30 Aug 2024 06:22:34 +0000 (08:22 +0200)
commite747e15156b79efeea0ad056df8de14b93d318c2
treebc352e2008d92204eb849eeb0b735436bca4c7e3
parentb9ca079dd6b09e08863aa998edf5c47597806c05
fs: try an opportunistic lookup for O_CREAT opens too

Today, when opening a file we'll typically do a fast lookup, but if
O_CREAT is set, the kernel always takes the exclusive inode lock. I
assume this was done with the expectation that O_CREAT means that we
always expect to do the create, but that's often not the case. Many
programs set O_CREAT even in scenarios where the file already exists.

This patch rearranges the pathwalk-for-open code to also attempt a
fast_lookup in certain O_CREAT cases. If a positive dentry is found, the
inode_lock can be avoided altogether, and if auditing isn't enabled, it
can stay in rcuwalk mode for the last step_into.

One notable exception that is hopefully temporary: if we're doing an
rcuwalk and auditing is enabled, skip the lookup_fast. Legitimizing the
dentry in that case is more expensive than taking the i_rwsem for now.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20240807-openfast-v3-1-040d132d2559@kernel.org
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
fs/namei.c