Date: Wed, 29 Apr 1998 06:32:46 +0200 From: Eivind Eklund <eivind@yes.no> To: Karl Denninger <karl@mcs.net>, Jason Nordwick <nordwick@scam.XCF.Berkeley.EDU> Cc: dyson@FreeBSD.ORG, Robert Withrow <witr@rwwa.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER Message-ID: <19980429063246.07285@follo.net> In-Reply-To: <19980428143114.33662@mcs.net>; from Karl Denninger on Tue, Apr 28, 1998 at 02:31:14PM -0500 References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> <19980428192742.1224.qmail@xcf.berkeley.edu> <19980428143114.33662@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 28, 1998 at 02:31:14PM -0500, Karl Denninger wrote: [... types of SIGDANGER handling...] > This leaves you with: > > 1) Do nothing - you get the semantics we have now. If the kernel > needs to whack you it will, without notice, but the warning > is ignored (you don't want to do anything with it). > > 2) Trap the signal - you get notice, and can clean up and exit if you > are able. You're still vulnerable, in that the kernel can whack > you if it needs to (and you're still around). The kernel can put > these processes into the "second round" bucket - it at least knows > that you're trying to help. > > 3) Set SIG_HOLD. You're a critical process and the kernel should go > pick on someone else if it can. If it can't, well, tough bananas, > but at least we tried to keep you going. We should distinguish between user processes and root processes somehow, too. A user shouldn't be able to make root's processes die unless the machine is explictly configured for that to be possible (IMO). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980429063246.07285>