Jason Thorpe wrote:
> The reaper was specifically added (by me) because these code paths CAN 
> block.  Any time you make a call into UVM, you are likely to take a 
> lock, which could block.

Indeed.

It may need to take lock from uvm_lwp_exit() -> uvm_uarea_free(),
and does need to take lock at least for i386 also in cpu_wait() ->
tss_free(). So the work indeed needs to be done from (separate)
process/lwp context.

I'm not sure about uvm_proc_exit() -> vmspace_free() - this may
be callable without process context, I can see only simplelocks
in the codepath. But since we need to execute the last (or only)
lwp before tearing down the process, even uvm_proc_exit()
can't be called sooner.
 
The option to make sys_wait4() able to collect info from SDEAD
process (with reaper still doing the final execution) is IMHO
fragile and I'd prefer to not go that path.

I guess the only remaining choice now is to make sys_wait4() able
to tear down SDEAD process completely itself if it gets to it before
the reaper, so that it wouldn't need to wait for reaper
to execute the child before collecting the child status. Would
this be somehow fundamentally wrong, or would this be okay to do?
The parent would get charged the time it would take to execute the
child, but IMHO this is fine. Arguably the time should be charged
to the child, but this might not be simple to implement. IIRC
parent is charged all the time the child run anyway, so it doesn't
matter much if the final teardown time is charged only to the parent
and not the child.

Opinions?

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-