All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Djalal Harouni <tixxdz@gmail.com>, Chris Mason <clm@fb.com>,
	tytso@mit.edu, Serge Hallyn <serge.hallyn@canonical.com>,
	Josh Triplett <josh@joshtriplett.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andy Lutomirski <luto@kernel.org>,
	Seth Forshee <seth.forshee@canonical.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Dongsu Park <dongsu@endocode.com>,
	David Herrmann <dh.herrmann@googlemail.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Alban Crequy <alban.crequy@gmail.com>
Subject: Re: [PATCH 1/1] shiftfs: uid/gid shifting bind mount
Date: Tue, 31 May 2016 22:51:02 -0400	[thread overview]
Message-ID: <1464749462.7732.15.camel@HansenPartnership.com> (raw)
In-Reply-To: <20160601023959.GF14480@ZenIV.linux.org.uk>

On Wed, 2016-06-01 at 03:40 +0100, Al Viro wrote:
> On Tue, May 31, 2016 at 08:31:33PM -0400, James Bottomley wrote:
> 
> 
> > +static struct dentry *shiftfs_lookup(struct inode *dir, struct
> > dentry *dentry,
> > +				     unsigned int flags)
> > +{
> > +	struct dentry *real = dir->i_private, *new;
> > +	struct inode *reali = real->d_inode, *newi;
> > +	const struct cred *oldcred, *newcred;
> > +
> > +	/* note: violation of usual fs rules here: dentries are
> > never
> > +	 * added with d_add.  This is because we want no dentry
> > cache
> > +	 * for shiftfs.  All lookups proceed through the dentry
> > cache
> > +	 * of the underlying filesystem, meaning we always see any
> > +	 * changes in the underlying */
> > +
> > +	inode_lock(reali);
> > +	oldcred = shiftfs_new_creds(&newcred, dentry->d_sb);
> > +	new = lookup_one_len(dentry->d_name.name, real, dentry
> > ->d_name.len);
> > +	shiftfs_old_creds(oldcred, &newcred);
> > +	inode_unlock(reali);
> > +
> > +	if (IS_ERR(new))
> > +		return new;
> > +
> > +	dentry->d_fsdata = new;
> > +
> > +	if (!new->d_inode)
> > +		return NULL;
> > +
> > +	newi = shiftfs_new_inode(dentry->d_sb, new->d_inode
> > ->i_mode, new);
> > +	if (!newi) {
> > +		dput(new);
> > +		return ERR_PTR(-ENOMEM);
> > +	}
> > +
> > +	d_splice_alias(newi, dentry);
> > +
> > +	return NULL;
> 
> This is utter crap.  First of all, d_splice_alias() *WILL* hash them, 
> so you get all the coherency problems, in spades.  Moreover, if you 
> did manage to avoid hashing, you would get something absolutely
> unusable.
> 	* no mounting of anything on top of that thing
> 	* performance shot to hell
> and that's just for starters.  I hadn't looked into the locking and 
> semantics issues - those would really depends upon how you would 
> achieve that "no dentry cache" thing; again, right now that's *not*
> what your code is doing.

Yes, sorry, after the new BUG_ON in the d_invalidate() code I didn't
have much choice but to run two sets of dentry hashes; I'm afraid I
just forgot to remove the comment (I did remove the blurb about the
single dentry cache from the changelog).  I'll remove it (the comment)
in the next go around.

> PS: and then there's the choice of name.  I mean, just try to say it 
> over the phone several times in a row...

But I did that especially for you, Al ...

James

  reply	other threads:[~2016-06-01  2:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01  0:29 [PATCH 0/1] shiftfs: uid/gid shifting filesystem James Bottomley
2016-06-01  0:31 ` [PATCH 1/1] shiftfs: uid/gid shifting bind mount James Bottomley
2016-06-01  2:40   ` Al Viro
2016-06-01  2:51     ` James Bottomley [this message]
2016-06-01 12:54 ` [PATCH 0/1] shiftfs: uid/gid shifting filesystem Michał Zegan
2016-06-01 16:21 ` Michał Zegan
2016-06-01 16:41   ` James Bottomley
2016-06-05 21:11     ` Djalal Harouni
2016-06-06 22:02       ` James Bottomley
2016-06-07 11:04         ` Djalal Harouni

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=1464749462.7732.15.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=alban.crequy@gmail.com \
    --cc=clm@fb.com \
    --cc=dh.herrmann@googlemail.com \
    --cc=dongsu@endocode.com \
    --cc=ebiederm@xmission.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=serge.hallyn@canonical.com \
    --cc=seth.forshee@canonical.com \
    --cc=tixxdz@gmail.com \
    --cc=tytso@mit.edu \
    --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.