Alan Jenkins <alan.christopher.jenkins@xxxxxxxxx> 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
