linux-kernel - Re: [PATCH 5/5] union: hybrid union filesystem prototype

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100902213315.GA16004@shell>
Date:	Thu, 2 Sep 2010 17:33:15 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	neilb@...e.de, viro@...iv.linux.org.uk, jblunck@...e.de,
	hch@...radead.org
Subject: Re: [PATCH 5/5] union: hybrid union filesystem prototype

On Thu, Sep 02, 2010 at 11:19:41AM +0200, Miklos Szeredi wrote:
> On Wed, 1 Sep 2010, Valerie Aurora wrote:
> > > +
> > > +		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.
> 
> Not a big deal, just set up nd as if this was a single component
> lookup.  The previous version did it like this:
> 
> +       struct nameidata nd = {
> +               .last_type = LAST_NORM,
> +               .last = *name,
> +       };
> +
> +       nd.path = pue->upperpath;
> +       path_get(&nd.path);
> +
> +       newdentry = lookup_create(&nd, S_ISDIR(attr->ia_mode));
> 
> But that's not a solution to the NFS suckage, it's just a workaround.

Hm, I suspect it's more complicated than this.  I looked at how
unionfs does it in init_lower_nd() and it requires poking around in
VFS internal details in the file system implementation.  So unioning
code is not in the VFS, but VFS code is in the union fs.  Progress?  I
dunno.

> "Fortunately" NFS isn't good for a writable layer of a union for other
> reasons, so this isn't a big concern at the moment.

It's the long-term effect on the code structure that concerns me more.

-VAL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/