Subject: Re: serious bug introduced in Linux compatibility
To: Jarommr Dolecek <jdolecek@netbsd.org>
From: Emmanuel Dreyfus <p99dreyf@criens.u-psud.fr>
List: tech-kern
Date: 03/24/2001 10:58:16
> Note linux_e_proc_exec() is also called via linux_e_proc_fork().
> The e_proc_fork() hook is called in fork1(), before the child's
> vmspace is set up (i.e. before call uvm_fork() - it has to be this
> way, since child uses completely different MD exit path from
> uvm_fork()).

Ok, this is the problem. I did not expect vmspace to be invalid when I
wrote ths brk() fix.

> So it's expected that the new process's vmspace would be invalid
> or NULL at time linux_e_proc_fork() is called. I have what I think
> is almost correct solution already (see "hard lockups with -current
> and Netscape" thread on current-users@); will commit it shortly.

In the meantime, shouldn't we bracket the brk() fix in linux_exec.c with
an #ifdef notyet?
This fix enabled java to run on the PowerPC, but it seems it broke lot
of things on other ports.

> Yeah, the bug was introduced in the recent brk-related commit.
> BTW, the brk() handling is not thread aware; all the
> threads should share single brk() value, since they also
> share vmspace, so that part of p_emuldata should be shared
> between threads. This may need a change to interface of e_proc_fork()
> hook, so that it would know fork1() flags and may act accordingly.

Do you already have an idea for this?

-- 
Emmanuel Dreyfus.  Cette signature vous est fournie telle quelle, sans 
aucune garantie de fonctionnement. En la lisant, vous acceptez 
implicitement tous les degats qu'elle pourrait causer, materiellement 
ou logiciellement.                   p99dreyf@criens.u-psud.fr