On 3/7/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> - when you do sys_unshare() or a clone that creates new namespaces, > then the task (or its child) will get a new nsproxy that has the rcfs > subsystem state associated with the old nsproxy, and one or more > namespace pointers cloned to point to new namespaces. So this means > that the nsproxy for the task is no longer the nsproxy associated with > any directory in rcfs. (So the task will disappear from any "tasks" > file in rcfs?) it "should" disappear yes, although I haven't carefully studied the unshare requirements yet.
That seems bad. With the current way you're doing it, if I mount hierarchies A and B on /mnt/A and /mnt/B, then initially all tasks are in /mnt/A/tasks and /mnt/B/tasks. If I then create /mnt/A/foo and move a process into it, that process disappears from /mnt/B/tasks, since its nsproxy no longer matches the nsproxy of B's root container. Or am I missing something? Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
