On Fri, Nov 29, 2002 at 05:55:48PM +0000, David Laight wrote:
> > > 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.
> 
> Well, firstly, the p_sigacts structure is 2052 bytes on my x86 system.
> (for some reason the kernal signal masks are 128 bits).
> This means that each item in the sigapl pool costs 4k (IIRC there
> was an issue on sun2 where the page size is only 2k...).

I was looking at 1.6.


> Secondly, unless the kernel is compiled with NOREDZONE, the kernel
> stack doesn't use the same page as the user area (this might not
> apply to all ports).

NOREDZONE is x86-only.


> Exchanging a page of wired memory for a page of swappable memory
> seems a win to me.

exchanging a page of memory for a lot less memory would be even better, no?


> > 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.
> 
> Except that the masks get changed quite frequently, so the searches
> could get quite expensive.

it's p->p_sigctx->ps_* that changes frequently, not the per-signal masks.



I was thinking about your original question again, and on second thought,
I don't see why moving cpu_fork() would help at all.  it's the last thing
called in uvm_fork(), so the only benefit of moving it to fork1() would be
if there was something that needed to be done after the rest of uvm_fork()
but cpu_fork().  why would playing with signal state need to go in between?

-Chuck