Re: [PATCH v2] fs: modify the annotation of vfs_mkdir() in fs/namei.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 14, 2024 at 11:29:38PM -0700, Christoph Hellwig wrote:
> On Sat, Jun 15, 2024 at 12:38:32PM +0800, Congjie Zhou wrote:
> > modify the annotation of @dir and @dentry
> 
> Well, it is clearly obvious that you modify them from the patch.  But
> why?

Look at the current comment:

 * @dir:        inode of @dentry

It is an inode of _some_ dentry; it's most definitely not that
of the argument named 'dentry'.

 * @dentry:     pointer to dentry of the base directory

No.  The first thing vfs_mkdir() does is
        int error = may_create(idmap, dir, dentry);

	if (error)
		return error;

Look at may_create().  Starts with
static inline int may_create(struct mnt_idmap *idmap,
                             struct inode *dir, struct dentry *child)
{
     audit_inode_child(dir, child, AUDIT_TYPE_CHILD_CREATE);
     if (child->d_inode)
	     return -EEXIST;

If the last argument (aka. 'dentry' argument of vfs_mkdir()) is currently
referring to *ANY* directory, you get -EEXIST.  For a good and simple
reason: it is the dentry of subdirectory to be created.  Now, the second
argument of vfs_mkdir() ('dir') is the inode of the parent to be (or base
directory, if you will).

While we are at it, the rest of comments coming from the same commit
suffer similar problems.  vfs_create(), vfs_symlink(), et.al.
vfs_unlink() is fine, vfs_rmdir() should match vfs_unlink() (inode of
parent + dentry of victim).




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux