From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [PATCH 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec Date: Wed, 23 Nov 2011 15:34:53 +0100 Message-ID: <20111123143444.GA14549@somewhere.redhat.com> References: <1320191193-8110-1-git-send-email-tj@kernel.org> <1320191193-8110-4-git-send-email-tj@kernel.org> <20111113164426.GB9446@somewhere> <20111114135404.GD9446@somewhere> <20111121220326.GM25776@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20111121220326.GM25776-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 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: Tejun Heo Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, rjw-KKrjLPT3xs0@public.gmane.org, linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org List-Id: containers.vger.kernel.org On Mon, Nov 21, 2011 at 02:03:26PM -0800, Tejun Heo wrote: > On Mon, Nov 14, 2011 at 02:54:08PM +0100, Frederic Weisbecker wrote: > > > Also note this is currently protected by the tasklist readlock. Cred guard mutex is > > > certainly better, I just don't remember if you remove the tasklist lock in a > > > further patch. > > > > Ah recalling what Ben Blum said, we also need the leader to stay stable because it > > is excpected to be passed in ->can_attach(), ->attach(), ->cancel_attach(), ... > > Although that's going to change after your patches that pass a flex array. > > Not really without locking out exec. The thing is whoever is exec'ing > will be the leader and we can't guarantee that the first in the flex > array is always the leader. One method may see it as the leader, the > next one might not. Exactly!