All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ian Kent <raven@themaw.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	autofs mailing list <autofs@linux.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] autofs4 - use lookup access intent to support recursive bind mounts
Date: Mon, 28 Apr 2008 08:05:14 +0100	[thread overview]
Message-ID: <20080428070514.GC5882@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1209364705.3243.1.camel@raven.themaw.net>

On Mon, Apr 28, 2008 at 02:38:25PM +0800, Ian Kent wrote:
> 
> On Mon, 2008-04-28 at 07:22 +0100, Al Viro wrote:
> > On Mon, Apr 28, 2008 at 02:14:54PM +0800, Ian Kent wrote:
> > > 
> > > Hi Andrew,
> > > 
> > > For autofs maps that recursively reference other map entries in their
> > > mount point path we need to ensure that these mounts are performed
> > > prior to the current mount request being done. We've used the access
> > > system call, made just prior to performing the mount, to make this
> > > happen. In the case of bind mounts, however, the lookup flags in 
> > > the path walk don't trigger a mount. To do this we need to also
> > > trigger a mount when we see the LOOKUP_ACCESS flag.
> > 
> > That's too fscking bad, since ->lookup() is about to lose access to
> > nameidata *and* flags for anything but the last step.  IOW, we'll need
> > cleaner solution...
> 
> Spell it out for me please!

->lookup() and friends are going to stop getting struct nameidata *.
->follow_link() obviously will keep it; ->d_revalidate() should
lose the sucker, but we might have to split it in two methods (which
is probably what'll be needed in your case).

At the same time struct open_intent is going to die, BTW, but that
won't matter for autofs, AFAICT.

  reply	other threads:[~2008-04-28  7:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-28  6:14 [PATCH] autofs4 - use lookup access intent to support recursive bind mounts Ian Kent
2008-04-28  6:22 ` Al Viro
2008-04-28  6:38   ` Ian Kent
2008-04-28  7:05     ` Al Viro [this message]
2008-04-28  7:25       ` Ian Kent
2008-04-28  7:53         ` Ian Kent

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=20080428070514.GC5882@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=autofs@linux.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    /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.