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:	Sat, 14 Jun 2008 00:15:31 -0400
From:	Valdis.Kletnieks@...edu
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	linux-kernel@...r.kernel.org, vatsa@...ux.vnet.ibm.com,
	a.p.zijlstra@...llo.nl
Subject: Re: odd timing bug with cgroups?

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.

It sounds like a variant of the race conditions we had a while back where
lots of programs blew chunks when we started having "child runs first"
semantics so children could run and exit before the parent was ready
for it?

Content of type "application/pgp-signature" skipped