Re: [9fans] bind, ns weirdness

Re: [9fans] bind, ns weirdness

[Keith Nash]

It seems a pity if there are valid namespaces that are not described by the present form of ns.

A possible solution is for /proc/$pid/ns to report every mount, bind and unmount that was ever executed by the process.  Why attempt to 'simplify' this script by removing matched groups of bind/mount and unmount, if the simplified script can't always tell us how the namespace was constructed?

Keith.

Re: [9fans] bind, ns weirdness

[Russ Cox]

ns is not manipulating the data.
it is showing you the internal
kernel data structures.  the kernel
doesn't keep the history of every
mount, bind, unmount, and in fact
the kernel doesn't keep the structure
as a list.  it keeps it as a hash table
for quick access, and the mount points
are represented by chans (think vnodes)
rather than actual path strings.  
when you look at just the strings
(as happens when it is presented in
the ns file) there is no guarantee that
the names are still valid.

as you point out the fundamental
problem here is that unmount removes
things from the hash table (and thus from
the list presented in /proc/$pid/ns),
things that other binds or mounts might
have depended on to make sense of the
names at the time.

it is entirely reasonable that unmount
removes things from the hash table:
they're gone!  then the chans can be
closed, and the resources reused.
in order to keep the entries in /proc/$pid/ns
around, the chans would have to be
kept open, which is against the point 
of unmount.  unmount means release
this binding, not make it invisible but
hold onto the resources.

perhaps some stub should remain in
the in-order list that has an empty 
chan structure with just a name,
so that the ns list is correct.  perhaps.

[9fans] bind, ns weirdness

[Joel Salomon]

> perhaps some stub should remain in
> the in-order list that has an empty 
> chan structure with just a name,
> so that the ns list is correct.  perhaps.

Would these stubs be #* style names (names outside of namespace)?
Still open chans might be given a # type name automagically if the
original is no longer in the namespace. Or is this being overly clever?

--Joel

Re: [9fans] bind, ns weirdness

[Russ Cox]

no, the name should remain unchanged.
if the name changes at all in the ns listing
then there's no point in keeping them around.
the whole point of the suggestion was to 
make the ns file effectively append-only,
so it shows a valid history.

russ

[9fans] bind, ns weirdness

[Keith Nash]

If, on my 4th Edition terminal, I run
   unmount /
then the binds
   bind / /
   bind -a /root /
   mount -a '#s/boot' /
get removed from the output of ns, as expected; the command
   ls -l /
shows that, indeed, the directories originally bound from the kfs disk /root are no longer there: only the files from '#/' are present.

There are two strange outcomes, which are probably related:

(1) 'man 1 ns' describes the output of ns as a script that could, in principle, recreate the name space.  The commands
bind /386/bin /bin
bind -a /rc/bin /bin
are still in the output from ns.  But /386 and /rc no longer exist; more importantly, /386 and /rc do not exist at the stage in the script when these binds would be run.

(2) ls and other commands in /bin that came from /386/bin can still be executed, although the bind that provides them is now nonsense; and ls -l /bin reports that the files from /386/bin and /rc/bin are still there - although only the former can be executed.

This situation persists even if I also unmount /root; but if I unmount /bin, the commands all disappear, as expected.

I have tried removing the -C flag from
mount -aC #s/boot /root $rootspec
in /lib/namespace, and rebooting, in case caching is having unexpected results.  This has no effect.

I would be grateful for any explanations!


Keith.

Re: [9fans] bind, ns weirdness

[David Presotto]

A process has an underlying idea of what / is, i.e., there is a
up->slash in the Proc structure of the process.  In all cases,
this is actually '#/'.  Therefore, after your 'unmount /',
an 'ls /' should show:

% ls -l /
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /bin
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /boot
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /dev
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /env
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /fd
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /mnt
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /net
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /net.alt
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /proc
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /root
d-r-xr-xr-x / 0 presotto presotto 0 Mar  3 11:05 /srv

In other words, you can't get rid of the underlying thing
that eveything else is mounted on.

All of the binds that happened onto / are indeed gone.
Therefore, there will be no /386.  However, /386/bin was
originally bound onto '#/'/bin which is still in your
namespace.  Therefore, it is still visible since it's
still in your namespace.

You're right that ns isn't good about figuring out
how to get back stuff that is no longer reachable.