From owner-freebsd-threads@FreeBSD.ORG Fri Sep 17 00:16:42 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E2EB16A4CE; Fri, 17 Sep 2004 00:16:42 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C111A43D1D; Fri, 17 Sep 2004 00:16:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i8H0GdML007605; Thu, 16 Sep 2004 20:16:39 -0400 (EDT) Date: Thu, 16 Sep 2004 20:16:39 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <414A2948.9000900@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv -FIXED- X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 00:16:42 -0000 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