Alan Jenkins <alan.christopher.jenk...@gmail.com> wrote:
> It sounds like you're under-estimating how we can use mnt_ns->seq (as is
> currently used in mnt_ns_loop()). Or maybe I am over-estimating it :).
I don't see how it helps. The duplication and attachment of the nsfs object
is already done by open_tree(), but as it's a detached tree, there are no
namespace assignments on the objects therein. move_mount() is attaching the
subtree as a whole.
I modified my example to put everything under /a, setting up initially on /a/x
and then moving to /a/y within the namespace. Then I made it print the mount
tree in more places. So after setup, I see:
[root@andromeda x]# findmnt -R /a
TARGET SOURCE
/a none
\_/a/x none
\_/a/x/private_mnt xxx
\_/a/x/private_mnt/child_ns nsfs[mnt:[4026532272]]
this looks fine. Then I do:
~/open_tree 3</a/x/private_mnt 3 \
nsenter --mount=/a/x/private_mnt/child_ns \
sh -c 'findmnt -R /a; ~/move_mount 4</a/y; findmnt -R /a'
and I see:
TARGET SOURCE
/a none
\_/a/x none
\_/a/x/private_mnt xxx
TARGET SOURCE
/a none
|_/a/x none
| \_/a/x/private_mnt xxx
\_/a/y xxx
\_/a/y/child_ns nsfs[mnt:[4026532272]]
in which /a/x/private_mnt got cloned and the clone mounted on "/a/y".
So, you're right, it's nothing to do with propagation. But I'm not sure how I
check this. Reject it in move_mount() if there's an nsfs? I'm not sure if
the seq number is actually useful here.
David
