On Thu, Sep 26, 2024 at 6:36 PM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > Ok, so here's my feeble attempt at getting something going for wrapping > struct pid_namespace as struct pid_namespace indirectly came up in the > file abstraction thread. This looks great! > The lifetime of a pid namespace is intimately tied to the lifetime of > task. The pid namespace of a task doesn't ever change. A > unshare(CLONE_NEWPID) or setns(fd_pidns/pidfd, CLONE_NEWPID) will not > change the task's pid namespace only the pid namespace of children > spawned by the task. This invariant is important to keep in mind. > > After a task is reaped it will be detached from its associated struct > pids via __unhash_process(). This will also set task->thread_pid to > NULL. > > In order to retrieve the pid namespace of a task task_active_pid_ns() > can be used. The helper works on both current and non-current taks but > the requirements are slightly different in both cases and it depends on > where the helper is called. > > The rules for this are simple but difficult for me to translate into > Rust. If task_active_pid_ns() is called on current then no RCU locking > is needed as current is obviously alive. On the other hand calling > task_active_pid_ns() after release_task() would work but it would mean > task_active_pid_ns() will return NULL. > > Calling task_active_pid_ns() on a non-current task, while valid, must be > under RCU or other protection mechanism as the task might be > release_task() and thus in __unhash_process(). Just to confirm, calling task_active_pid_ns() on a non-current task requires the rcu lock even if you own a refcont on the task? Alice