Oleg Nesterov <oleg@xxxxxxxxxx> writes: > sorry for delay, vacation... > > On 04/28, Kirill Tkhai wrote: >> >> On 27.04.2017 19:22, Oleg Nesterov wrote: >> > >> > Ah, OK, I didn't notice the ns->child_reaper check in pidns_for_children_get(). >> > >> > But note that it doesn't need tasklist_lock too. >> >> Hm, are there possible strange situations with memory ordering, when we see >> ns->child_reaper of already died ns, which was placed in the same memory? >> Do we have to use some memory barriers here? > > Could you spell please? I don't understand your concerns... > > I don't see how, say, > > static struct ns_common *pidns_for_children_get(struct task_struct *task) > { > struct ns_common *ns = NULL; > struct pid_namespace *pid_ns; > > task_lock(task); > if (task->nsproxy) { > pid_ns = task->nsproxy->pid_ns_for_children; > if (pid_ns->child_reaper) { > ns = &pid_ns->ns; > get_pid_ns(ns); > } > } > task_unlock(task); > > return ns; > } > > can be wrong. It also looks more clean to me. > > ->child_reaper is not stable without tasklist, it can be dead/etc, but > we do not care? It breaks a number of assumptions if you can join a pid namespace before an init process is created in that pid namespace. Checking for child_reaper is a bit heavy handed but appears to ensure all of the assumptions of initial pid namespace creation have been met. Which means your simplified pidns_for_children_get is a bit insufficient. Eric