SIGILL @ pthread_create() after execv -FIXED-

[Daniel Eischen]

On Thu, 16 Sep 2004, Julian Elischer wrote:

>
>
> Daniel Eischen wrote:
>
> >On Fri, 17 Sep 2004, David Xu wrote:
> >
> >
> >>Daniel Eischen wrote:
> >>
> >>
> >>>We do that in fork().  Is execv() not being done after a fork()?
> >>>
> >>>
> >>>
> >>>
> >>Joost calls execv() directly in threaded process, he did not go through
> >>fork() ->execv() path.
> >>
> >
> >Yes, Julian just emailed me similarly.  In that case, I think we need
> >to wrap execve() and set the kernel signal mask to the threads signal
> >mask.  We don't need all the single threading stuff that is in our
> >wrapped fork(); just __sys_sigprocmask() should be sufficient.  Right?
> >
>
> We would need to ensure that there is no chance that we could be
> switched to another kernel thread between the two calls.

True.

> In general I'd prefer it if we had a way that worked even if the
> userland screwed up..
> execve is often a way in which daemons recover when they feel that they
> have messed up in some way...
>
> e.g.:
> panic()
> {
>        log("help I've fallen over and I can't get up");
>        execve( me, argc, argv, envpp);  /* or whatever the args are ..ok
> so I need to write more userland stuff */_
> }
> do we trust userland that much?
>
> does the signal therad just enable ALL signals?
> does it not maks those for which we have no consumers?

Regardless, it doesn't have the signal mask that the execve()'ing thread
has, and that is the key issue.  The exec'd process needs to have the
signal mask of the issuing thread.

> I'd still prefer to do things that work for libthr as well as libpthread.

I don't see why this (whatever we do) has to be any different for libthr.

For libpthread, we could put ourselves in a critical region (clear
the mailbox) -- that would stop upcalls.  Does that also prevent
switching to different kernel threads?

-- 
Dan Eischen