linux-kernel - Re: [GIT PULL] sched/core for v2.6.32

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]

Message-ID: <alpine.LFD.2.01.0909111546050.3654@localhost.localdomain>
Date:	Fri, 11 Sep 2009 15:58:34 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesper Juhl <jj@...osbits.net>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>
Subject: Re: [GIT PULL] sched/core for v2.6.32

On Sat, 12 Sep 2009, Jesper Juhl wrote:
> [...]
> > Highlights:
> > 
> >  - Child-runs-first is now off - i.e. we run parent first.
> >    [ Warning: this might trigger races in user-space. ]
> [...]
> 
> Ouch. Do we dare do that?

We would want to at least try.

There are various reasons why we'd like to run the child first, ranging 
from just pure latency (quite often, the child is the one that is 
critical) to getting rid of page sharing for COW early thanks to execve 
etc.

But similarly, there are various reasons to run the parent first, like 
just the fact that we already have the state active in the TLB's and 
caches.

Finally, we've never made any guarantees, because the timeslice for the 
parent might be just about to end, so child-first vs parent-first is never 
a guarantee, it's always just a preference.

[ And we _have_ had that preference expose user-level bugs. Long long ago 
  we hit some problem with child-runs-first and 'bash' being unhappy about 
  a really low-cost and quick child process exiting even _before_ bash 
  itself had had time to fill in the process tables, and then when the 
  SIGCHLD handler ran bash said "I got a SIGCHLD for something I don't 
  even know about". 

  That was very much a bash bug, but it was a bash bug that forced us to 
  do 'parent-runs-first' for a while. So the heuristic can show problems ]

> vfork() is supposed to always run the child first.

vfork() has always run the child first, since the parent won't even be 
runnable. The parent will get stuck in

	wait_for_completion(&vfork);

so the "child-runs-first" is just an issue for regular fork or clone, not 
vfork. For vfork there is never any question about it.

> Most people I've talked to over the years assume that using fork(), the 
> child runs first (yes, I know, that's not guaranteed, but people have come 
> to believe that it is so and some may even depend on it).

It really hasn't been that way in Linux. We've done it both ways. 

			Linus
--
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/