All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valerie Aurora <vaurora@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	neilb@suse.de, viro@zeniv.linux.org.uk, jblunck@suse.de,
	hch@infradead.org
Subject: Re: [PATCH 5/5] union: hybrid union filesystem prototype
Date: Wed, 1 Sep 2010 17:42:38 -0400	[thread overview]
Message-ID: <20100901214238.GC15849@shell> (raw)
In-Reply-To: <20100826183507.402136609@szeredi.hu>

On Thu, Aug 26, 2010 at 08:33:45PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi <mszeredi@suse.cz>
> 
> This union filesystem is a hybrid of entirely filesystem based
> (unionfs, aufs) and entierly VFS based (union mounts) solutions.

This is elegant and readable code.  I am still reviewing it but have a
few comments now.

> +static int union_upper_create(struct dentry *dentry, struct iattr *attr,
> +			      dev_t rdev, const char *link, struct path *src)
> +{
> +	int err;
> +	int attr_update = ATTR_UID | ATTR_GID | ATTR_ATIME_SET | ATTR_MTIME_SET;
> +	struct dentry *parent = dget_parent(dentry);
> +	struct union_entry *ue = dentry->d_fsdata;
> +	struct union_entry *pue = parent->d_fsdata;
> +	struct inode *upperdir = pue->upperpath.dentry->d_inode;
> +	struct dentry *newdentry;
> +	struct path newpath;
> +
> +	mutex_lock_nested(&upperdir->i_mutex, I_MUTEX_PARENT);
> +
> +	/*
> +	 * Using upper filesystem locking to protect against copy up
> +	 * racing with rename (rename means the copy up was already
> +	 * successful).
> +	 */
> +	err = -EEXIST;
> +	if (dentry->d_parent != parent)
> +		goto out_unlock;
> +
> +	newdentry = union_lookup_create(ue, pue, &dentry->d_name);
> +	err = PTR_ERR(newdentry);
> +	if (IS_ERR(newdentry))
> +		goto out_unlock;
> +
> +	newpath.dentry = newdentry;
> +	newpath.mnt = pue->upperpath.mnt;
> +
> +	switch (attr->ia_mode & S_IFMT) {
> +	case S_IFREG:
> +		if (src)
> +			WARN_ON(!(attr->ia_valid & ATTR_SIZE));
> +		else
> +			WARN_ON((attr->ia_valid & ATTR_SIZE));
> +
> +		err = vfs_create(upperdir, newdentry, attr->ia_mode, NULL);

Passing a NULL namiedata pointer to vfs_create() is a convenient
temporary hack, but unfortunately NFS, ceph, etc. still use the
nameidata passed to vfs_create() and other ops.

The way union mounts gets a valid nameidata is by doing the create in
the VFS before calling file system ops that may trigger a copyup,
while we still have the original nameidata.  This is one of the major
reasons union mounts lives in the VFS.

A lot of my conversations about union mounts with Al go like this:

Al: "Rewrite it this way."
Val: "But then how do we get the nameidata?"
Al: "Arrrrrrrrrrrrrggggh."

Can you think of a way to construct a good nameidata for these
implicit copyups?  That might be a solution.

-VAL

  reply	other threads:[~2010-09-01 21:43 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-26 18:33 [PATCH 0/5] hybrid union filesystem prototype Miklos Szeredi
2010-08-26 18:33 ` [PATCH 1/5] vfs: implement open "forwarding" Miklos Szeredi
2010-08-26 18:33 ` [PATCH 2/5] vfs: make i_op->permission take a dentry instead of an inode Miklos Szeredi
2010-08-26 20:24   ` David P. Quigley
2010-08-27  4:11     ` Neil Brown
2010-08-27 18:13       ` David P. Quigley
2010-08-27 19:21         ` Valerie Aurora
2010-08-27 18:31       ` David P. Quigley
2010-08-26 18:33 ` [PATCH 3/5] vfs: add flag to allow rename to same inode Miklos Szeredi
2010-08-26 18:33 ` [PATCH 4/5] vfs: export do_splice_direct() to modules Miklos Szeredi
2010-08-26 18:33 ` [PATCH 5/5] union: hybrid union filesystem prototype Miklos Szeredi
2010-09-01 21:42   ` Valerie Aurora [this message]
2010-09-02  9:19     ` Miklos Szeredi
2010-09-02 21:33       ` Valerie Aurora
2010-09-03  5:10         ` Neil Brown
2010-09-03  9:16           ` Miklos Szeredi
2010-09-09 16:02             ` David P. Quigley
2010-09-03  8:52         ` Miklos Szeredi
2010-09-02 21:42   ` Valerie Aurora
2010-09-03 12:31     ` Miklos Szeredi
2010-08-27  7:05 ` [PATCH 0/5] " Neil Brown
2010-08-27  8:47   ` Miklos Szeredi
2010-08-27 11:35     ` Neil Brown
2010-08-27 16:53       ` Miklos Szeredi
2010-08-29  4:42         ` Neil Brown
2010-08-30 10:18           ` Miklos Szeredi
2010-08-30 11:40             ` Neil Brown
2010-08-30 12:20               ` Miklos Szeredi
2010-08-31 19:18                 ` Valerie Aurora
2010-08-31 20:19                   ` Trond Myklebust
2010-09-01  1:56                     ` Valerie Aurora
2010-09-01  4:04                       ` Trond Myklebust
2010-09-01  4:33               ` Neil Brown
2010-09-01 20:11                 ` Miklos Szeredi
2010-08-31 19:29             ` Valerie Aurora
2010-09-02 13:15             ` Jan Engelhardt
2010-09-02 13:32               ` Neil Brown
2010-09-02 14:25                 ` Jan Engelhardt
2010-09-02 14:28                   ` Miklos Szeredi
2010-09-08 19:47                     ` David P. Quigley
2010-09-23 13:18                   ` Jan Engelhardt
2010-09-23 19:22                     ` Valerie Aurora
2010-08-30 18:38       ` Valerie Aurora
2010-08-30 23:12         ` Neil Brown
2010-08-31 11:00           ` Miklos Szeredi
2010-08-31 11:24             ` Neil Brown
2010-08-31 15:05               ` Kyle Moffett
2010-08-31 15:05                 ` Kyle Moffett
2010-08-31 20:36                 ` Valerie Aurora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100901214238.GC15849@shell \
    --to=vaurora@redhat.com \
    --cc=hch@infradead.org \
    --cc=jblunck@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=neilb@suse.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.