Date: Sun, 16 Dec 2012 19:05:48 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Adrian Chadd <adrian@freebsd.org>, Andriy Gapon <avg@freebsd.org>, Ian Lepore <freebsd@damnhippie.dyndns.org>, Peter Wemm <peter@wemm.org>, Peter Jeremy <peter@rulingia.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r244112 - head/sys/kern Message-ID: <CAJ-Vmo=XPXAAV90ZNqbky8kBfxGdQ6iB6GX4YQ_oQayeKiNWFQ@mail.gmail.com> In-Reply-To: <20121216233213.GA1451@itx> References: <201212121658.49048.jhb@freebsd.org> <50C90567.8080406@FreeBSD.org> <50C909BD.9090709@mu.org> <50C91B32.4080904@FreeBSD.org> <20121215205202.GF1411@garage.freebsd.pl> <20121216040717.GG35245@server.rulingia.com> <CAGE5yCofnCKfJ8kMKrV8fmckPt_WOXc9PGnh3zuVUSGO-%2BrCRQ@mail.gmail.com> <1355634037.1198.115.camel@revolution.hippie.lan> <50CD7C1D.3020108@FreeBSD.org> <CAJ-Vmo=4HNhWYSgGBn%2BTae%2B6UO9dqnim_hvcabsCy8Nq-9=bOA@mail.gmail.com> <20121216233213.GA1451@itx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 December 2012 15:32, Navdeep Parhar <nparhar@gmail.com> wrote: >> The status quo _does not change_ by default. > > So now we have a knob that could be used to change the behaviour of all > the KASSERTs in the system; one that hints that it may be possible to > continue even if an assertion in the FreeBSD kernel doesn't hold good > (this is the part that bothers me). I know all the KASSERTs I've looked > at or written are genuine assertions -- the code simply wouldn't be able > to cope if they were violated. You'd get NULL dereferences, or worse, > access protected structures without corresponding locks held, etc. In that case, those failures should be handled gracefully, or they should immediately panic the kernel. Claiming that a KASSERT() is optional at this point is basically us as a project saying "We know that if the kernel gets to this point and it fails this check, everything is busted after this." Ie, "Hey, if you disable KASSERT(), your data is potentially toast." Yet we ship with KASSERT() disabled. Silent data corruption, race conditions, etc. Not everything leads to a NULL pointer dereference. Again, we ship with KASSERT disabled in GENERIC on shipping production releases. The concerns you have with KASSERT printing out when Alfred's modification is enabled -does not change the fact that the kernel does _EXACTLY THIS_ kind of "oh well, I'll keep going" behaviour in a GENERIC, production, release kernel-. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=XPXAAV90ZNqbky8kBfxGdQ6iB6GX4YQ_oQayeKiNWFQ>