From owner-freebsd-current@FreeBSD.ORG Sat Feb 28 20:32:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ACE116A4CE for ; Sat, 28 Feb 2004 20:32:34 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id C14EC43D2D for ; Sat, 28 Feb 2004 20:32:31 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i1T4WUAK010039; Sun, 29 Feb 2004 15:32:30 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1T4WReV030933; Sun, 29 Feb 2004 15:32:28 +1100 Date: Sun, 29 Feb 2004 15:32:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kris Kennaway In-Reply-To: <20040228231118.GA45137@xor.obsecurity.org> Message-ID: <20040229151547.J8824@gamplex.bde.org> References: <26964.1078007698@critter.freebsd.dk> <20040228231118.GA45137@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Poul-Henning Kamp cc: current@freebsd.org Subject: Re: failed to set signal flags properly for ast() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 04:32:34 -0000 On Sat, 28 Feb 2004, Kris Kennaway wrote: > On Sat, Feb 28, 2004 at 11:34:58PM +0100, Poul-Henning Kamp wrote: > > > > On a -current kernel from this morning, I ran a "make -j 12 -s buildworld". > > > > At some point I pressed ctrl-Z and it started spitting tons of > > failed to set signal flags properly for ast() > > out on the serial console, but after about a minute it stopped and the system > > continued. > > I've been reporting this for a year or so..no-one seems to be too > interested in tracking it down. I tracked it down, but no one replied. Basically, the SIGPENDING() check is not strict enough, or issignal() doesn't do enough. issignal() can return with signals pending according to SIGPENDING(). Then the next userret() will report problems unless something in between sets TDF_ASTPENDING and TDF_NEEDSIGCHK again to schedule another (null) call to issignal(). The problem can't be fixed simply by removing the diagnostic, since lots of places use SIGPENDING() to determine whether they should set the TDF flags. But setting the TDF flags unnecessarily is just a pessimization, and nothing seems to break if the diagnostic is turned off, so it seems that the diagnostic is just about the pessimization. Bruce