From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [RFC][PATCH] Make access to taks's nsproxy liter Date: Thu, 09 Aug 2007 11:10:33 +0400 Message-ID: <46BABDE9.6090508@openvz.org> References: <46B9E321.6070602@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: Linux Containers , Oleg Nesterov List-Id: containers.vger.kernel.org Eric W. Biederman wrote: > Pavel Emelyanov writes: > >> When someone wants to deal with some other taks's namespaces >> it has to lock the task and then to get the desired namespace >> if the one exists. This is slow on read-only paths and may be >> impossible in some cases. >> >> E.g. Oleg recently noticed a race between unshare() and the >> (just sent for review) pid namespaces - when the task notifies >> the parent it has to know the parent's namespace, but taking >> the task_lock() is impossible there - the code is under write >> locked tasklist lock. >> >> On the other hand switching the namespace on task (daemonize) >> and releasing the namespace (after the last task exit) is rather >> rare operation and we can sacrifice its speed to solve the >> issues above. > > > Looks pretty decent but we need to clearly say what lock > you have to have to assign to the nsproxy pointer. no locks - only current is allowed to change its nsproxy! > In this case it isn't so much of a lock as simply you must > be the process so I think the code is ok. But it sufficiently > subtle it probably needs to be spelled out. > > Eric >