hi,

On Fri, Nov 29, 2002 at 03:55:38PM +0000, David Laight wrote:
> At the momemt fork1() calls uvm_form() which then calls cpu_fork().
> 
> ISTM that it would be better for fork1() to call cpu_fork() after
> uvm_fork() returns.

that seems fine in general.  however...


> This would enable process setup that required access to the user
> area to be put into (the more logical) fork1() routine, instead
> of having to hide it in uvm_fork().
> 
> At the moment the only such code is that which sets up the p->p_stats
> area.  However I have just made a kernel which puts p->p_sigacts
> into the user area [1].  This requires sigactsinit() to be called
> after the child's user area has been locked down.

this may not be such a good idea.  that eats either 1.5k or 2k (depending
on whether it's a 32- or 64-bit kernel) from the kernel stack, which would
greatly increase the likelyhood of a stack overflow.  in order to counteract
that we'd probably have to increase the stack size, which would negate any
benefit from making the signal info pageable.

perhaps a better way to reduce the memory usage of the signal info
would be to add another layer of indirection and do the sharing and
reference-counting on a per-signal basis as well as a per-signal-set basis.
or maybe even instead of the per-signal-set basis, my workstation right now
has 341 processes and 331 elements in use in the "sigapl" pool, so there's
hardly any sharing going on at the per-signal-set level anyway.

it may even make sense to attempt to detect when unrelated processes
can share the signal info.  I imagine that every instance of (eg.) sh or tcsh
installs identical signal handlers that could be shared, even though
the processes are not related.


> I've also noticed the PHOLD(p1) and PRELE(p1) in fork1().
> Surely p1 is the active process so cannot be swapped?
> What must be necessary is to stop p2 (the child) being swapped?

I think you're right, yea.

-Chuck