lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 2 May 2017 20:33:00 +0300 From: Kirill Tkhai <ktkhai@...tuozzo.com> To: Oleg Nesterov <oleg@...hat.com> CC: <serge@...lyn.com>, <ebiederm@...ssion.com>, <agruenba@...hat.com>, <linux-api@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <paul@...l-moore.com>, <viro@...iv.linux.org.uk>, <avagin@...nvz.org>, <linux-fsdevel@...r.kernel.org>, <mtk.manpages@...il.com>, <akpm@...ux-foundation.org>, <luto@...capital.net>, <gorcunov@...nvz.org>, <mingo@...nel.org>, <keescook@...omium.org> Subject: Re: [PATCH 2/2] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy On 02.05.2017 19:33, Oleg Nesterov wrote: > 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? I mean the following. We had a pid_ns1 with a child_reaper set. Then it became dead, and a new pid_ns2 were allocated in the same memory. A task on another cpu opens the pid_for_children file, and because of there is no memory ordering, it sees pid_ns1->child_reaper, when it opens pid_ns2. I forgot, what guarantees this situation is impossible? What guarantees, the renewed content of pid_ns2 on another cpu is seen not later, than we can't open it?
Powered by blists - more mailing lists