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

[Jori Koolstra <jkoolstra@xs4all.nl>]

> Op 03-06-2026 01:00 CEST schreef NeilBrown <neilb@ownmail.net>:
> 
>  
> 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@xs4all.nl>
> > ---
> >  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.
> 

Ah, yes, I see. I have changed this now.

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

I can do that as well if you want, crediting you. I am busy on these
things now anyway.

> Thanks,
> NeilBrown

All the best,
Jori.