From owner-cvs-all Mon May 7 12:15: 6 2001 Delivered-To: cvs-all@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9216B37B423; Mon, 7 May 2001 12:15:02 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id PAA13915; Mon, 7 May 2001 15:14:26 -0400 (EDT) Date: Mon, 7 May 2001 15:14:26 -0400 (EDT) From: Daniel Eischen To: Akinori MUSHA Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_fork.c src/sys/kern kern_fork.c kern_sig.c In-Reply-To: <200105071807.f47I7TB61684@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 7 May 2001, Akinori MUSHA wrote: > knu 2001/05/07 11:07:29 PDT > > Modified files: > lib/libc_r/uthread uthread_fork.c > sys/kern kern_fork.c kern_sig.c > Log: > Properly copy the P_ALTSTACK flag in struct proc::p_flag to the child > process on fork(2). > > It is the supposed behavior stated in the manpage of sigaction(2), and > Solaris, NetBSD and FreeBSD 3-STABLE correctly do so. > > The previous fix against libc_r/uthread/uthread_fork.c fixed the > problem only for the programs linked with libc_r, so back it out and > fix fork(2) itself to help those not linked with libc_r as well. On a related note, there were some changes a while ago to Linux emulation that used the alternate signal stack based on whether the process stack pointer was in the alternate stack or not. I think we currently have to reinstall the alternate signal stack everytime we longjmp out of a signal handler. Can't our kernel be smart enough to know that we're not on the alternate signal stack and use it without having to call sigaltstack each time we leave a signal handler via longjmp? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message