Prev: drivers/media/video: Remove dead CONFIG_OLPC_X0_1
Next: [patch 4/5] x86: Add xsaveopt cpufeature
From: Valerie Aurora on 19 Jul 2010 18:50 On Tue, Jul 13, 2010 at 12:56:20PM +0800, Ian Kent wrote: > On Tue, Jun 15, 2010 at 11:39:57AM -0700, Valerie Aurora wrote: > > When a file on the read-only layer of a union mount is altered, it > > must be copied up to the topmost read-write layer. This patch creates > > union_copyup() and its supporting routines. > > > > Thanks to Valdis Kletnieks for a bug fix. > > > > Cc: Valdis.Kletnieks(a)vt.edu > > --- > > fs/union.c | 323 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > fs/union.h | 7 +- > > 2 files changed, 329 insertions(+), 1 deletions(-) > > > > diff --git a/fs/union.c b/fs/union.c > > index 76a6c34..0982446 100644 > > --- a/fs/union.c > > +++ b/fs/union.c > > +/** > > + * do_union_copyup_len - Copy up a file given its path (and its parent's) > > + * > > + * @nd: nameidata for topmost parent dir > > + * @path: path of file to be copied up > > + * @copy_all: if set, copy all of the file's data and ignore @len > > + * @len: if @copy_all is not set, number of bytes of file data to copy up > > + * > > + * Newly copied up path is returned in @path. > > + */ > > + > > +static int do_union_copyup_len(struct nameidata *nd, struct path *path, > > + int copy_all, size_t len) > > +{ > > + struct path *parent = &nd->path; > > + int error; > > + > > + if (!IS_DIR_UNIONED(parent->dentry)) > > + return 0; > > + if (parent->mnt == path->mnt) > > + return 0; > > + if (!S_ISREG(path->dentry->d_inode->i_mode) && > > + !S_ISLNK(path->dentry->d_inode->i_mode)) > > + return 0; > > + > > + BUG_ON(!S_ISDIR(parent->dentry->d_inode->i_mode)); > > + > > + mutex_lock(&parent->dentry->d_inode->i_mutex); > > + error = -ENOENT; > > + if (IS_DEADDIR(parent->dentry->d_inode)) > > + goto out_unlock; > > + > > + if (copy_all && S_ISREG(path->dentry->d_inode->i_mode)) { > > + error = -EFBIG; > > + len = i_size_read(path->dentry->d_inode); > > + if (((size_t)len != len) || ((ssize_t)len != len)) > > + goto out_unlock; > > OK, call me dumb, but what does this comparison of len to len do? It checks if len (the size of the file to be copied up) will overflow size_t or ssize_t on this machine. The file could have been created on a 64-bit box, and be too big to be manipulated on a 32-bit box. It could use a comment, fixed. -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Miklos Szeredi on 4 Aug 2010 11:30 On Tue, 15 Jun 2010, Valerie Aurora wrote: > When a file on the read-only layer of a union mount is altered, it > must be copied up to the topmost read-write layer. This patch creates > union_copyup() and its supporting routines. > > Thanks to Valdis Kletnieks for a bug fix. What happens if there's a crash in the middle of the copyup? Possible solution is using rename to atomically "replace" the underlying file. That however introduces namespace issues: where to put the temporary file which then needs to be deleted on "fsck.union"? Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valerie Aurora on 5 Aug 2010 16:00 On Wed, Aug 04, 2010 at 05:26:28PM +0200, Miklos Szeredi wrote: > On Tue, 15 Jun 2010, Valerie Aurora wrote: > > When a file on the read-only layer of a union mount is altered, it > > must be copied up to the topmost read-write layer. This patch creates > > union_copyup() and its supporting routines. > > > > Thanks to Valdis Kletnieks for a bug fix. > > What happens if there's a crash in the middle of the copyup? > > Possible solution is using rename to atomically "replace" the > underlying file. That however introduces namespace issues: where to > put the temporary file which then needs to be deleted on "fsck.union"? This kind of problem is what makes union mounts so much fun to work on!! </sarcasm> So far this version of union mounts has kept the namespace clean, so I'd like to keep it that way. One of my ideas is to mark the new file as "copy-in-progress" and if we encounter such a file, we restart the copyup again. But how to mark it? A new inode flag? This applies in some form to directory copyup too. However, we already have a flag we use to indicate that it's copied up - the opaque flag. I moved that to be set after the directory entries are copied up. If it crashes in the middle, it can be safely restarted the next time we call readdir() on that directory. I added a comment to the commit message describing the problem, so it's at least documented. -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: drivers/media/video: Remove dead CONFIG_OLPC_X0_1 Next: [patch 4/5] x86: Add xsaveopt cpufeature |