Re: [RFC PATCH v6 3/9] vfs: prepare vfs_creat|mkdir_no_perm for reuse in lookup_open()

From: NeilBrown

Date: Tue Jun 02 2026 - 19:06:09 EST


On Mon, 01 Jun 2026, Jori Koolstra wrote:
> To implement O_CREAT|O_DIRECTORY we will have to repeat some of the
> logic that is now in vfs_mkdir() (e.g. do error checks in the same
> order). Separate this out in vfs_mkdir_no_perm(), which does all the
> non-permission related work of vfs_mkdir(). Permission checking for the
> lookup_open() path is timed differently because we may just be doing an
> open and no create. Similar considerations give rise to
> vfs_create_no_perm().
>
> Moving the fsnotify_* calls also allows us to deal with this in one
> place for each type of operation. This does mean that we also need
> to move the fsnotify_* calls into atomic_open() for the atomic open
> case, but this actually reduces duplicate code in open_last_lookups()
> and dentry_create().
>
> Signed-off-by: Jori Koolstra <jkoolstra@xxxxxxxxx>
> ---
> fs/namei.c | 105 ++++++++++++++++++++++++++++++++++-------------------
> 1 file changed, 68 insertions(+), 37 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 4cd132fe3981..2a35dd72ee96 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -4171,6 +4171,24 @@ static inline umode_t vfs_prepare_mode(struct mnt_idmap *idmap,
> return mode;
> }
>
> +static inline
> +int vfs_create_no_perm(struct mnt_idmap *idmap, struct dentry *dentry,
> + umode_t mode, struct delegated_inode *di, bool excl)
>

I meant to mention this on my first review but got distracted.

I would rather this function didn't have the "bool excl" arg, not
because it is "bool", but because it is not needed.
The 'excl' flag to ->create is not needed and I would like to get rid of
it. We don't have to do that immediately, but I'd rather not perpetuate
it.

There are two sort of fileystems - local and cluster.
cluster filesystems support ->atomic_open and so ->create is *never*
called with 'excl' false. All vfs_create() calls (which are either mknod or
internal) are exclusive.

local filesystems do not support ->atomic_open but *always* ignore the
excl flag. The only time ->create is called with 'excl' being false is
after VFS has already checked that the file doesn't exist, and is
holding a lock so that the there cannot be a concurrent create.

So we can change all filesystems that currently notice 'excl' to assume
that it is always 'true' and we can deprecate the flag.

Maybe I should post some patches, but for you could leave the 'bool
excl' out of this patch, that would be great.

Thanks,
NeilBrown