Re: [PATCH v2 7/7] Use simple_start_creating() in various places.

[Jeff Layton <jlayton@kernel.org>]

On Wed, 2025-09-10 at 21:30 +1000, NeilBrown wrote:
> On Wed, 10 Sep 2025, Jeff Layton wrote:
> > On Wed, 2025-09-10 at 08:37 +0100, Al Viro wrote:
> > > > ... and see viro/vfs.git#work.persistency for the part of the queue that
> > > > had order already settled down (I'm reshuffling the tail at the moment;
> > > > hypfs commit is still in the leftovers pile - the whole thing used to
> > > > have a really messy topology, with most of the prep work that used to
> > > > be the cause of that topology already in mainline - e.g. rpc_pipefs
> > > > series, securityfs one, etc.)
> > > 
> > > Speaking of which, nfsctl series contains the following and I'd like to
> > > make sure that behaviour being fixed there *is* just an accident...
> > > Could nfsd folks comment?
> > > 
> > > [PATCH] nfsctl: don't bump st_nlink of directory when creating a symlink in it
> > >     
> > > 
> > > apparently blindly copied from mkdir...
> > >     
> > > 
> > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> > > ---
> > > diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
> > > index bc6b776fc657..282b961d8788 100644
> > > --- a/fs/nfsd/nfsctl.c
> > > +++ b/fs/nfsd/nfsctl.c
> > > @@ -1181,7 +1181,6 @@ static int __nfsd_symlink(struct inode *dir, struct dentry *dentry,
> > >  	inode->i_size = strlen(content);
> > >  
> > > 
> > >  	d_add(dentry, inode);
> > > -	inc_nlink(dir);
> > >  	fsnotify_create(dir, dentry);
> > >  	return 0;
> > >  }
> > 
> > That is increasing the link count on the parent because it's adding a
> > dentry to "dir". The link count on a dir doesn't have much meaning, but
> > why do we need to remove it here, but keep the one in __nfsd_mkdir?
> 
> The link count in an inode is the number of links *to* the inode.
> A symlink (or file etc) in a directory doesn't imply a link to that
> directory (they are links "from" the directory, but those aren't counted).
> A directory in a directory, on the other hand, does imply a link to the
> (parent) directory due to the ".." entry.
> 
> In fact the link count on a directory should always be 2 plus the number
> of subdirectories (one for the name in the parent, one for "." in the
> directory itself, and one for ".." in each subdirectory).  Some "find"
> style programs depend on that to a degree, though mostly as an
> optimisation.
> 

I'm having a hard time finding where that is defined in the POSIX
specs. The link count for normal files is fairly well-defined. The link
count for directories has always been more nebulous.

I think we would be well-served by a clearly-defined meaning for the
link count on a directory for Linux, because different filesystems do
this differently today.

Yours and Al's semantics seem fine (I don't have a real preference,
tbh), but we should codify this in Documentation/ since it is unclear.
-- 
Jeff Layton <jlayton@kernel.org>