Date: Wed, 19 Dec 2012 17:32:15 -0500 From: John Baldwin <jhb@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Andriy Gapon <avg@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Navdeep Parhar <np@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-head@freebsd.org Subject: Re: svn commit: r244112 - head/sys/kern Message-ID: <201212191732.15777.jhb@freebsd.org> In-Reply-To: <50D0EED3.8020301@mu.org> References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212181537.23341.jhb@freebsd.org> <50D0EED3.8020301@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, December 18, 2012 5:31:47 pm Alfred Perlstein wrote: > On 12/18/12 12:37 PM, John Baldwin wrote: > > On Monday, December 17, 2012 4:21:43 pm Alfred Perlstein wrote: > >> On 12/17/12 11:39 AM, John Baldwin wrote: > >>> On Saturday, December 15, 2012 1:04:17 am Bruce Evans wrote: > >>>> On Fri, 14 Dec 2012, Alfred Perlstein wrote: > >>>> > >>>>> On 12/14/12 4:12 PM, Robert Watson wrote: > >>>>>> On Fri, 14 Dec 2012, John Baldwin wrote: > >>>>>> > >>>>>>> On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote: > >>>>>>>> On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote: A> The > >>>>>>>> problem again is that not all the KASSERTS are inviolable, if you A> want > >>>>>>>> to do a project to split them, then please do, it would really be A> > >>>>>>>> helpful, as for now, they are a mis-mash of death/warnings and there are > >>>>>>>> A> at least three vendors who approve of this as well as 3 long term A> > >>>>>>>> committers that approved my change (not including Adrian). > >>>>>>>> > >>>>>>>> Can you show examples of not inviolable KASSERTs? > >>>>>>> There are none. They are all assertions for a reason. However, in my > >>>> Not even one whose existence is a bug? :-) > >>> They should just not exist at all then. :) All the more reason for them to > >>> panic early and often so developers will be prompted to remove them. > >>> > >> This is hard to explain to a customer. > >> > >> customer: "So we ran your debug image and got you a panic, here is the > >> information. So can you tell us what is the problem?" > >> alfred: "well that is due to XXX other thing that is broken, thanks for > >> helping us resolve that unrelated problem!" > >> customer: "i hate you" > >> alfred: "get in line." > > Are your customers running HEAD? Assertions in a stable branch have been > > through testing and generally aren't bogus, so dying on incorrect assertions > > (meaning the assertion tripped for non-buggy code) should not be the common > > case. Thus, that shouldn't really be the basis for an argument on this. > > > > I can also come up with arbitrary strawmen: > > > > customer: "help! we lost a bunch of data!" > > jhb: "oh, well, I can see why: the box reported this critical error while > > your data was still there, but it went ahead and corrupted it all > > anyway even though it knew about the error because I thought you wanted > > longer uptimes" > > jhb: "don't worry, I have a patch to fix the error" > > customer: "don't bother, we are switching to X" > > > > Yes, that happens when they run -stable. No, the kernel doesn't "know" it's going to corrupt the data if assertions aren't enabled. If you had something that only selectively enabled certain assertions that would be fine, but in my use case I'd still want them to always panic. That would just give you a more fine-grained tool for how much performance you are willing to sacrafice for extra safety. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201212191732.15777.jhb>