From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [RFC][PATCH] Make access to taks's nsproxy liter Date: Wed, 08 Aug 2007 10:29:18 -0600 Message-ID: References: <46B9E321.6070602@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <46B9E321.6070602-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> (Pavel Emelyanov's message of "Wed, 08 Aug 2007 19:37:05 +0400") 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: Pavel Emelyanov Cc: Linux Containers , Oleg Nesterov List-Id: containers.vger.kernel.org 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. 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