Race in ovl_copy_up()?

Race in ovl_copy_up()?

[David Howells]

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

Re: Race in ovl_copy_up()?

[Miklos Szeredi]

On Mon, Aug 11, 2014 at 4:37 PM, David Howells <dhowells@redhat.com> wrote:

> 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.

Locking upperdir should be enough protection.

Lets say we have a race:

A: copy_up(a/b/c/d)
B: copy_up(a/b/e/f)

Both ascend to "b" and try to lock "a".  The one that wins the lock
acquisition will do the copy-up, the other one will just skip it once
it gets the lock.

Thanks,
Miklos