From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753616Ab1LUSXy (ORCPT ); Wed, 21 Dec 2011 13:23:54 -0500 Received: from mail-ww0-f44.google.com ([74.125.82.44]:51207 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752969Ab1LUSXv (ORCPT ); Wed, 21 Dec 2011 13:23:51 -0500 Date: Wed, 21 Dec 2011 19:23:46 +0100 From: Frederic Weisbecker To: Oleg Nesterov Cc: Li Zefan , Tejun Heo , LKML , Mandeep Singh Baines , Containers , Cgroups , KAMEZAWA Hiroyuki , Paul Menage , Andrew Morton , "Paul E. McKenney" Subject: Re: Q: cgroup: Questions about possible issues in cgroup locking Message-ID: <20111221182344.GH17668@somewhere> References: <20111221034334.GD17668@somewhere> <20111221130848.GA19679@redhat.com> <20111221175943.GG17668@somewhere> <20111221181101.GA3092@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111221181101.GA3092@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 21, 2011 at 07:11:01PM +0100, Oleg Nesterov wrote: > On 12/21, Frederic Weisbecker wrote: > > > > On Wed, Dec 21, 2011 at 02:08:48PM +0100, Oleg Nesterov wrote: > > > On 12/21, Frederic Weisbecker wrote: > > > > - By the time we call cgroup_post_fork(), it is ready to be woken up > > > > and usable by the scheduler. > > > > > > No, the new child can't run until do_fork()->wake_up_new_task(). > > > > Out of curiosity, why is it not possible for a task to kill and wake up the child > > before that happens? > > Because it is not possible to wake it up. > > Please note that copy_process() creates the "deactivated" child, iow > it is not on rq. > > But, at the same time its ->state == TASK_RUNNING. This "fools" > try_to_wake_up() or anything else which in theory could place it > on the runqueue. Aaah I see. > > Except, of course, wake_up_new_task() does activate_task(). And > note that it does this unconditionally, exactly because we know that > this task can't be woken. > ok, thanks for the explanation! From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: Q: cgroup: Questions about possible issues in cgroup locking Date: Wed, 21 Dec 2011 19:23:46 +0100 Message-ID: <20111221182344.GH17668@somewhere> References: <20111221034334.GD17668@somewhere> <20111221130848.GA19679@redhat.com> <20111221175943.GG17668@somewhere> <20111221181101.GA3092@redhat.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nVlLZRf1VrRVxYDPxRTVbP3saKN+ONzmMaWhCK+nfa8=; b=YKNyhYwntcBU+j4nR2wfEudlCmwI/CEHEA7cgzncnONwxWvnGJGZ/cgARzUKm6j2WX e95wkMxrOwaCDQ9PhFzLCPWWTV1NyjXvOkQQzefGgcl1AMtmxJPy4jh3mPzxbCxwME+r lzbxjSr/sZu1JVCXuCFVdaQ6NF5F++bpC5jSY= Content-Disposition: inline In-Reply-To: <20111221181101.GA3092-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Oleg Nesterov Cc: Li Zefan , Tejun Heo , LKML , Mandeep Singh Baines , Containers , Cgroups , KAMEZAWA Hiroyuki , Paul Menage , Andrew Morton , "Paul E. McKenney" On Wed, Dec 21, 2011 at 07:11:01PM +0100, Oleg Nesterov wrote: > On 12/21, Frederic Weisbecker wrote: > > > > On Wed, Dec 21, 2011 at 02:08:48PM +0100, Oleg Nesterov wrote: > > > On 12/21, Frederic Weisbecker wrote: > > > > - By the time we call cgroup_post_fork(), it is ready to be woken up > > > > and usable by the scheduler. > > > > > > No, the new child can't run until do_fork()->wake_up_new_task(). > > > > Out of curiosity, why is it not possible for a task to kill and wake up the child > > before that happens? > > Because it is not possible to wake it up. > > Please note that copy_process() creates the "deactivated" child, iow > it is not on rq. > > But, at the same time its ->state == TASK_RUNNING. This "fools" > try_to_wake_up() or anything else which in theory could place it > on the runqueue. Aaah I see. > > Except, of course, wake_up_new_task() does activate_task(). And > note that it does this unconditionally, exactly because we know that > this task can't be woken. > ok, thanks for the explanation!