Date: Sun, 29 Feb 2004 15:32:26 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Kris Kennaway <kris@obsecurity.org> Cc: current@freebsd.org Subject: Re: failed to set signal flags properly for ast() Message-ID: <20040229151547.J8824@gamplex.bde.org> In-Reply-To: <20040228231118.GA45137@xor.obsecurity.org> References: <26964.1078007698@critter.freebsd.dk> <20040228231118.GA45137@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040229151547.J8824>