Date: Wed, 12 Dec 2012 14:15:23 -0800 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r244112 - head/sys/kern Message-ID: <CAJ-Vmom8aivK7Z95%2BSwigReOTdn-OwXspK3pXO=0CVr1y1Unzg@mail.gmail.com> In-Reply-To: <201212121658.49048.jhb@freebsd.org> References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <CAJ-Vmo=U04GX%2BZyKuzXLwV%2BPpzU6_dm5BCmL=DWfsmhTVAR%2BsA@mail.gmail.com> <201212121658.49048.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 December 2012 13:58, John Baldwin <jhb@freebsd.org> wrote: >> Anything which is a KASSERT() can and should be treated as a run-time >> warning just as much as a run-time "crash here so I can figure out >> what broke." Having the warning in a production box is going to be >> helpful for developers. > > Hmmm, I'll have to chew on this. Adding lots of returns because panic's are > now no longer dead2 was why I ended up backing the removal of the > RESTARTABLE_PANICS option. Yes, for panic() as it stands it should just do that - panic. We should likely go over the panic()s and replace them with kassert+handle gracefully wherever its appropriate (there are a few places in net80211 for example that I'd like to do this.) But you're right. For panic(), the rest of the code likely doesn't handle or continue gracefully, so we shouldn't automatically disable them. But this is about KASSERT(). Alfred mixed this in with witness "non panic" mode, which I think is what's confusing people. > I'm inclined to say that it's really bad to let a kernel known to be in a > bad state continue, and that if someone has asked for the slowdown of all > the extra checks INVARIANTS adds, they might as well minimize the chance for > data corruption by having the kernel stop as soon as a problem is detected. Right, but that should be an option. It'd be nice if we were able to dump out some system state when an invariant condition or witness issue was hit (like a mini scripted ddb dump - say, log things like the current lock state) but then continue. > (Note that the primary reason I know for people not running with INVARIANTS > enabled is not that they don't want panics, but that they don't want the > performance hit.) Well, it would be nice to be able to enable invariants on some shipping "debug" versions of images in order to gather more data without crashing the kernel. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom8aivK7Z95%2BSwigReOTdn-OwXspK3pXO=0CVr1y1Unzg>