On Fri, 06 Sep 2013 16:54:19 +0800
Ian Kent wrote:
>
> Sorry, I should have added Jeff to the cc for this post.
>
> On Fri, 2013-09-06 at 16:38 +0800, Ian Kent wrote:
> > On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> > > On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > > > I'v
Sorry, I should have added Jeff to the cc for this post.
On Fri, 2013-09-06 at 16:38 +0800, Ian Kent wrote:
> On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> > On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > > I've applied slightly modified variant of Jeff's "vfs: allow umount to
On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > I've applied slightly modified variant of Jeff's "vfs: allow umount to
> > handle
> > mountpoints without revalidating them" (modified by just leaving the
> > struct path filled with mo
On Wed, 04 Sep 2013 12:07:28 +0800
Ian Kent wrote:
> On Wed, 2013-09-04 at 11:53 +0800, Ian Kent wrote:
> > On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> > > On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > > > I've applied slightly modified variant of Jeff's "vfs: allow umount
On Wed, 2013-09-04 at 11:53 +0800, Ian Kent wrote:
> On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> > On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > > I've applied slightly modified variant of Jeff's "vfs: allow umount to
> > > handle
> > > mountpoints without revalidating them"
On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > I've applied slightly modified variant of Jeff's "vfs: allow umount to
> > handle
> > mountpoints without revalidating them" (modified by just leaving the
> > struct path filled with mo
On Tue, 2013-09-03 at 19:18 -0700, Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 7:00 PM, Al Viro wrote:
> >
> > That aside, I'm really not happy with this kind of games; this stuff clearly
> > belongs in fs/namei.c where we can simply see the last component. Doing
> > that
> > on the level of
On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> I've applied slightly modified variant of Jeff's "vfs: allow umount to handle
> mountpoints without revalidating them" (modified by just leaving the
> struct path filled with mountpoint and leaving the equivalent of
> follow_mount()
> to c
On Tue, Sep 03, 2013 at 07:18:42PM -0700, Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 7:00 PM, Al Viro wrote:
> >
> > That aside, I'm really not happy with this kind of games; this stuff clearly
> > belongs in fs/namei.c where we can simply see the last component. Doing
> > that
> > on the le
On Tue, Sep 3, 2013 at 7:00 PM, Al Viro wrote:
>
> That aside, I'm really not happy with this kind of games; this stuff clearly
> belongs in fs/namei.c where we can simply see the last component. Doing that
> on the level of "let's scan the pathname for slashes, etc." is just plain
> wrong. Let'
On Wed, Sep 04, 2013 at 02:03:02AM +0100, Al Viro wrote:
> E... NAK in that form. Just what will happen if the last component
> given to that sucker will be . or .., for starters? Or a symlink, with
> '/' added to it to force following the damn thing?
OK, in more details:
* we are
On Wed, Sep 04, 2013 at 08:54:57AM +0800, Ian Kent wrote:
> +static int kern_path_top(const char *pathname,
> + unsigned int flags, struct path *path)
> +{
> + struct dentry *dentry;
> + struct qstr name;
> + const char *tmp;
> + unsigned int len;
> + int er
When reconnecting to automounts at startup an autofs ioctl is used
to find the device and inode of existing mounts so they can be used
to open a file descriptor of possibly covered mounts.
At this time the the caller might not yet "own" the mount so it can
trigger calling ->d_automount(). This cau
13 matches
Mail list logo
