linux-kernel - Re: odd timing bug with cgroups?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Jun 2008 10:45:09 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Valdis.Kletnieks@...edu
CC:	linux-kernel@...r.kernel.org, vatsa@...ux.vnet.ibm.com,
	a.p.zijlstra@...llo.nl
Subject: Re: odd timing bug with cgroups?

Valdis.Kletnieks@...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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/