LKML Archive on
help / color / mirror / Atom feed
From: Andreas Gruenbacher <>
To: Linus Torvalds <>
	Andrew Morton <>,
	Al Viro <>,, Tony Jones <>,
	Neil Brown <>, Christoph Hellwig <>,
	Greg Kroah-Hartman <>, walt <>
Subject: Re: [PATCH] Fix d_path for lazy unmounts
Date: Wed, 14 Feb 2007 14:57:50 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wednesday 14 February 2007 11:39, Andreas Gruenbacher wrote:
> On Wednesday 14 February 2007 07:37, Linus Torvalds wrote:
> > We could prepend another '/' (so that you'd have a path that starts with
> > "//"). That's still a legal path, but it's also somethign that even POSIX
> > says is valid to mean something else (eg "//ftp/.." or "//socket/.." to
> > escape into another namespace).
> This sounds good enough to me. My main point is that users that care should
> be able to tell the difference.

Looking some more into it, appending another slash doesn't look like the best 
solution after all. Here is a more elaborate description of the cases we have 
to deal with:

 * Regular paths that lead up to the root we are interested in. These should
   obviously be reported as "/dir/file", so I won't mention them any further.

 * Files on pseudo filesystems such as pipefs. Historically, we are
   reporting them as "pipe:[439336]" or similar, where "pipe:" is the name of
   the root dentry, and "[439336]" is the name of the child; no slash between

 * Lazily unmounted directories. Currently, we report them as "dirfile", where
   "dir" is the name of the directory dentry, and "file" is the name of the
   child dentry. That's the obvious bug.

 * Lazily unmounted filesystems. Currently, they and up as "/file", where
   "/" is the name of the root dentry, and "file" is the name of the
   child dentry.

 * Unreachable paths. Currently, we report them as absolute paths, so there
   is no way to tell the one from the other.

What I'm after here is two things:

 (1) fix the bug with the lazily unmounted dirs, and

 (2) allow to tell when a path is unreachable.

The key problem is that we know when we hit a disconnected path, but it's hard 
to tell the pseudo filesystem case from the root filesystem case because 
rootfs also is a pseudo filesystem.

Let's look at a few choices we have:

[0] Now:
pipe:			"pipe:[439336]"
lazily umounted dir:	"dirfile"		<==  bug
lazily unmounted fs:	"/file"			<== ambiguous
path on rootfs:		"/file"			<== ambiguous
rootfs root:		"/"			<== ambiguous

[1] Always make disconnected paths relative:
pipe:			"pipe:[439336]" (or "pipe/[439336]")
lazily umounted dir:	"dir/file"
lazily unmounted fs:	"file"
path on rootfs:		"file"
rootfs root:		"."

[2] Make disconnected pseudo-fs paths relative and others absolute;
    special case the rootfs:
pipe:			"pipe:[439336]" (or "pipe/[439336]")
lazily umounted dir:	"//dir/file"
lazily unmounted fs:	"//file"
path on rootfs:		"//file"
rootfs root:		"//"

[3] Always make disconnected paths double-slashed:
pipe:			"//pipe/[439336]"
lazily umounted dir:	"//dir/file"
lazily unmounted fs:	"//file"
unreachable root:	"//"

>From all these choices, I actually like [1] best, together with hiding 
unreachable mount points in /proc/$pid/mounts and /proc/$pid/mountstats: 
there is no real point in pretending that unreachable paths are reachable; 
whichever process uses these paths is just as much in error when trying from 
the pwd as when trying from the chroot.

Hiding unreachable mount points has the benefits that processes will not get 
to see relative paths in /proc/$pid/mounts and /proc/$pid/mountstats. Those 
paths are irrelevant to them anyway; just consider a chroot()ed process that 
currently sees all sorts of crap.

A process that hasn't been chroot()ed will still see all filesystems except 
the rootfs, so no problem there. Hiding the rootfs by virtue of it being 
unreachable is actually be a good thing: nobody is actually going to be able 
to do anything with it anyway; it's just confusing, and adds unnecessary 
special cases to scripts like mkinitrd.

I would actually also prefer to see the hack go that leaves out the slash 
between pathame components (so "pipe:[439336]" would just 
become "pipe/[439336]") -- it's good for nothing other than backward 



  reply	other threads:[~2007-02-14 22:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-03  3:23 Andreas Gruenbacher
2007-02-05  0:15 ` Neil Brown
2007-02-15  2:43   ` Andreas Gruenbacher
2007-02-05  8:32 ` Andreas Gruenbacher
2007-02-05 18:37   ` [PATCH]Add memory barrier before clear bit in unlock_buffer() Mingming Cao
2007-02-14  8:19   ` [PATCH] Fix d_path for lazy unmounts Andreas Gruenbacher
2007-02-14  8:29     ` Olaf Hering
2007-02-14  8:42       ` Andreas Gruenbacher
2007-02-14 15:37     ` Linus Torvalds
2007-02-14 19:39       ` Andreas Gruenbacher
2007-02-14 22:57         ` Andreas Gruenbacher [this message]
2007-02-15  3:13           ` Andreas Gruenbacher
2007-02-17 13:30             ` Andreas Gruenbacher
2007-02-15 12:53           ` Jan Engelhardt
2007-02-15 13:19             ` Andreas Gruenbacher

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] Fix d_path for lazy unmounts' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).