All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Johansen <john.johansen@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Fix __d_path for lazy unmounts
Date: Fri, 26 Feb 2010 09:07:45 -0800	[thread overview]
Message-ID: <4B87FFE1.7040001@canonical.com> (raw)
In-Reply-To: <E1NkyyX-0000l1-01@pomaz-ex.szeredi.hu>

On 02/26/2010 04:07 AM, Miklos Szeredi wrote:
> On Sat, 20 Feb 2010, john.johansen@canonical.co wrote:
>> From: John Johansen<john.johansen@canonical.com>
>>
>> When __d_path() hits a lazily unmounted mount point, it tries to prepend
>> the name of the lazily unmounted dentry to the path name.  It gets this wrong,
>> and also overwrites the slash that separates the name from the following
>> pathname component. This patch fixes that; if a process was in directory
>> /foo/bar and /foo got lazily unmounted, the old result was ``foobar'' (note the
>> missing slash), while the new result with this patch is ``/foo/bar''.
>
> Example:
>
> # mkdir -p /tmp/foo/bar
> # mkdir /tmp/mnt
> # mount --bind /tmp/foo /tmp/mnt
> # cd /tmp/mnt/bar
> # /bin/pwd
> /tmp/mnt/bar
> # umount -l /tmp/mnt
> # /bin/pwd
> foobar
>
> After the patch it will be /foo/bar.
>
> Why is the path starting with "/foo"?  Does that make any sense?
>
not a lot except, connecting disconnected paths to root is what
is currently done for paths that aren't reachable but have an fs
as their root (ie the last dentry is / so it looks connected to
root).

I would be happy in this case to leave bind mounts disconnected
(no leading /) and just fix the overwriting of the internal /.

I'll make the change.

> Last time this was discussed the proposals which are halfway sane
> were:
>
>   a) "(unreachable)/bar" or something along those lines
>   b) ENOENT
>
right, I actually have another couple of __d_path patches I need
to kick out for discussion.  Last time we rolled 3 different
changes into a single patch.  This time I wanted to isolate the
changes per patch.  I'll kick them all out today.

> And with either one care needs to be taken to limit this change to
> interfaces (both internal and userspace) where it's not likely to
> cause breakage.
>
agreed.


  reply	other threads:[~2010-02-26 17:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-20 12:27 [PATCH] Fix __d_path for lazy unmounts john.johansen
2010-02-22 17:24 ` John Johansen
2010-02-22 17:38 ` Serge E. Hallyn
2010-02-23  0:17 ` Andrew Morton
2010-02-23  1:04   ` Serge E. Hallyn
2010-02-24  0:12     ` [Patch 0/1] Fix __d_path for lazy unmounts v2 john.johansen
2010-02-24  0:12     ` [PATCH] Fix __d_path for lazy unmounts john.johansen
2010-02-23  1:56   ` John Johansen
2010-02-26 12:07 ` Miklos Szeredi
2010-02-26 17:07   ` John Johansen [this message]
2010-03-01 10:05     ` Miklos Szeredi

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=4B87FFE1.7040001@canonical.com \
    --to=john.johansen@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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.