On Wednesday 14 February 2007 19:13, Andreas Gruenbacher wrote:
> So here is how this could be implemented. See the lengthy explanations in
> the patch headers, too.
Turns out I messed up with one of Neil's review comments. Here is yet another
update.
With this fix, everything works as expected
On Wednesday 14 February 2007 19:13, Andreas Gruenbacher wrote:
So here is how this could be implemented. See the lengthy explanations in
the patch headers, too.
Turns out I messed up with one of Neil's review comments. Here is yet another
update.
With this fix, everything works as expected
On Thursday 15 February 2007 04:53, Jan Engelhardt wrote:
> What's the point in changing pipefs... you can *never*
> reach it *anyway*, even if it was a /-style path, since
> pipefs is a NOMNT filesystem.
The point is that we could then get rid of the special case for MS_NOUSER
filesystems like
Hi,
On Feb 14 2007 14:57, Andreas Gruenbacher wrote:
>[2]
>
>pipe: "pipe:[439336]" (or "pipe/[439336]")
>
>[3] Always make disconnected paths double-slashed:
>--
>pipe: "//pipe/[439336]"
Hi,
On Feb 14 2007 14:57, Andreas Gruenbacher wrote:
[2]
pipe: pipe:[439336] (or pipe/[439336])
[3] Always make disconnected paths double-slashed:
--
pipe: //pipe/[439336]
lazily
On Thursday 15 February 2007 04:53, Jan Engelhardt wrote:
What's the point in changing pipefs... you can *never*
reach it *anyway*, even if it was a /-style path, since
pipefs is a NOMNT filesystem.
The point is that we could then get rid of the special case for MS_NOUSER
filesystems like
On Wednesday 14 February 2007 14:57, Andreas Gruenbacher wrote:
> [1] Always make disconnected paths relative:
>
> 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
On Sunday 04 February 2007 16:15, Neil Brown wrote:
> The behaviour in the face of a lazy unmount should be clarified in
> this comment.
Done.
> If sys_getcwd is called on a directory that is no longer
> connected to the root, it isn't clear to me that it should return
> without an error.
>
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
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
On Wed, 14 Feb 2007, Andreas Gruenbacher wrote:
>
> Mountpoints are reported relative to the chroot if they are reachable from
> the
> chroot, and relative to the namespace they are defined in otherwise. This is
> big nonsense, but it's unclear to me how to best fix it:
Well, it's also what
On Wednesday 14 February 2007 00:29, Olaf Hering wrote:
> On Wed, Feb 14, Andreas Gruenbacher wrote:
> > What's the point in reporting the rootfs at all -- it's never reachable
> > to an ordinary process?
>
> /init and its childs has it as root, until it passes control over to
> /sbin/init
Yes,
On Wed, Feb 14, Andreas Gruenbacher wrote:
> What's the point in reporting the rootfs at all -- it's never reachable to an
> ordinary process?
/init and its childs has it as root, until it passes control over to
/sbin/init
-
To unsubscribe from this list: send the line "unsubscribe
On Monday 05 February 2007 00:32, Andreas Gruenbacher wrote:
> Here is an updated patch that also catches this special case.
> [...]
The d_path change was to not start unreachable paths with slashes. In the
extreme case, this leads to an empty string. As it turns out, we are
reporting
On Monday 05 February 2007 00:32, Andreas Gruenbacher wrote:
Here is an updated patch that also catches this special case.
[...]
The d_path change was to not start unreachable paths with slashes. In the
extreme case, this leads to an empty string. As it turns out, we are
reporting meaningless
On Wed, Feb 14, Andreas Gruenbacher wrote:
What's the point in reporting the rootfs at all -- it's never reachable to an
ordinary process?
/init and its childs has it as root, until it passes control over to
/sbin/init
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Wednesday 14 February 2007 00:29, Olaf Hering wrote:
On Wed, Feb 14, Andreas Gruenbacher wrote:
What's the point in reporting the rootfs at all -- it's never reachable
to an ordinary process?
/init and its childs has it as root, until it passes control over to
/sbin/init
Yes, that's
On Wed, 14 Feb 2007, Andreas Gruenbacher wrote:
Mountpoints are reported relative to the chroot if they are reachable from
the
chroot, and relative to the namespace they are defined in otherwise. This is
big nonsense, but it's unclear to me how to best fix it:
Well, it's also what a
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
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
On Sunday 04 February 2007 16:15, Neil Brown wrote:
The behaviour in the face of a lazy unmount should be clarified in
this comment.
Done.
If sys_getcwd is called on a directory that is no longer
connected to the root, it isn't clear to me that it should return
without an error.
Without
On Wednesday 14 February 2007 14:57, Andreas Gruenbacher wrote:
[1] Always make disconnected paths relative:
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
On Friday 02 February 2007 19:23, Andreas Gruenbacher wrote:
> Hello,
>
> here is a bugfix to d_path. Please apply (after 2.6.20).
>
> First, 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
On Friday 02 February 2007 19:23, Andreas Gruenbacher wrote:
Hello,
here is a bugfix to d_path. Please apply (after 2.6.20).
First, 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
On Friday February 2, [EMAIL PROTECTED] wrote:
> Hello,
>
> here is a bugfix to d_path. Please apply (after 2.6.20).
Looks good! Just a couple of little comments (to prove that I have
really read it and thought about it :-)
>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
On Friday February 2, [EMAIL PROTECTED] wrote:
Hello,
here is a bugfix to d_path. Please apply (after 2.6.20).
Looks good! Just a couple of little comments (to prove that I have
really read it and thought about it :-)
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Reviewed-by:
Hello,
here is a bugfix to d_path. Please apply (after 2.6.20).
First, 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
Hello,
here is a bugfix to d_path. Please apply (after 2.6.20).
First, 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
28 matches
Mail list logo
