Message-ID: <48569895.7020701@nortel.com>
Date: Mon, 16 Jun 2008 10:45:09 -0600
From: "Chris Friesen" <cfriesen@nortel.com>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
MIME-Version: 1.0
To: Valdis.Kletnieks@vt.edu
CC: linux-kernel@vger.kernel.org, vatsa@linux.vnet.ibm.com,
       a.p.zijlstra@chello.nl
Subject: Re: odd timing bug with cgroups?
References: <4852E8D5.3000503@nortel.com> <47364.1213416931@turing-police.cc.vt.edu>
In-Reply-To: <47364.1213416931@turing-police.cc.vt.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1149
Lines: 26

Valdis.Kletnieks@vt.edu wrote:
> On Fri, 13 Jun 2008 15:38:29 MDT, Chris Friesen said:

>>This seems odd...I would think that as soon as the fork() call returns 
>>in the parent we should be able to put that task into a group.

> I'm admittedly shooting in the dark here, but remember that a successful
> fork() call returns *twice*.  Just because the *parent* has returned
> doesn't mean that the *child* has finished all the processing and returned
> as well - it may be delayed by other kernel threads etc and still not quite
> ready for tweaking.

I was thinking something like this as well, like maybe we can't move the 
child to another group until it gets scheduled in once, or something 
similar.

If that is the case, I think it's a bug--on return from fork() the 
child's pid is visible (because the parent knows it) and so it should be 
valid to use for any operation that takes a pid.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/