Race in ovl_copy_up()?

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

 



Hi Miklos,

Looking at the following:

	int ovl_copy_up(struct dentry *dentry)
	{
		int err;

		err = 0;
		while (!err) {
			struct dentry *next;
			struct dentry *parent;
			struct path lowerpath;
			struct kstat stat;
			enum ovl_path_type type = ovl_path_type(dentry);

			if (type != OVL_PATH_LOWER)
				break;

			next = dget(dentry);
			/* find the topmost dentry not yet copied up */
			for (;;) {
				parent = dget_parent(next);

				type = ovl_path_type(parent);
				if (type != OVL_PATH_LOWER)
					break;

				dput(next);
				next = parent;
			}

			ovl_path_lower(next, &lowerpath);
			err = vfs_getattr(&lowerpath, &stat);
			if (!err)
				err = ovl_copy_up_one(parent, next, &lowerpath, &stat);

			dput(parent);
			dput(next);
		}

		return err;
	}

In the for-loop in the middle, if you ascend any levels at all, how are you
protected from racing with copy-ups taking place on those more rootwards
dentries?

I can see ovl_copy_up_one() using lock_rename() on the workdir and upperdir,
but there's no relevant lock on the overlayfs fs.  You stepped out of the lock
the VFS caller holds when you ascended.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux