Date: Thu, 15 Nov 2012 17:58:27 +0000 From: Attilio Rao <attilio@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Ian Lepore <freebsd@damnhippie.dyndns.org>, Adrian Chadd <adrian@freebsd.org>, freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [RFQ] make witness panic an option Message-ID: <CAJ-FndCcTxdr=4ifewc6349M4Z3DUx7mrAEed2VCgDwuL95OKA@mail.gmail.com> In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <CAJ-Vmo=i=Amo_QqHi4GnGie0Gc0YnK3XaRKjvBO-=SFboFYPmA@mail.gmail.com> <1353001175.1217.153.camel@revolution.hippie.lan> <CAJ-FndBP5Pi=SCpyBLK3b=HM_gQ9u8M4%2B1tLk9tA5X-gqismVA@mail.gmail.com> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/15/12, Warner Losh <imp@bsdimp.com> wrote: > > On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > >> On 11/15/12, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote: >>> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>>> Hi all, >>>> >>>> When debugging and writing wireless drivers/stack code, I like to >>>> sprinkle lots of locking assertions everywhere. However, this does >>>> cause things to panic quite often during active development. >>>> >>>> This patch (against stable/9) makes the actual panic itself >>>> configurable. It still prints the message regardless. >>>> >>>> This has allowed me to sprinkle more locking assertions everywhere to >>>> investigate whether particular paths have been hit or not. I don't >>>> necessarily want those to panic the kernel. >>>> >>>> I'd like everyone to consider this for FreeBSD-HEAD. >>>> >>>> Thanks! >>> >>> I strongly support this, because I'm tired of having to hack it in by >>> hand every time I need it. >>> >>> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >>> without a LOR very early in the boot. Once you get past that, 2 or 3 >>> device drivers I use panic way before we even get to mounting root. >>> Those panics can clearly be ignored, because we've been shipping >>> products for years based on this code. (It's on my to-do list to fix >>> them, but more pressing problems are higher on the list.) >> >> This is a ridicolous motivation. >> What are the panics in question? Why they are not fixed yet? >> Without WITNESS_KDB you should not panic even in cases where WITNESS >> yells. So if you do, it means there is a more subdole breakage going >> on here. >> >> Do you really think that an abusable mechanism will help here rather >> than fixing the actual problems? >> >>> When a new problem crops up that isn't harmless, it totally sucks that I >>> can't just turn on witness without first hacking the code to make the >>> known problems non-panicky. >> >> I really don't understand what are these "harmless problems" here. >> I just know one and it is between the dirhash lock and the bufwait >> lock for UFS, which is carefully documented in the code comments. All >> the others cases haven't been analyzed deeply enough to quantify them >> as "harmless". >> >> Can you please make real examples? > > It sounds like he's more worried about introducing LoRs into his wireless > code. They are harmless, for him, and he can fix them by reloading the > driver. They are only harmful if he loses a race. Without WITNESS_KDB the kernel won't panic if this is really the case, if it is only about LOR yelling. Otherwise the breakage is more serious and I would like to see a real case example. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndCcTxdr=4ifewc6349M4Z3DUx7mrAEed2VCgDwuL95OKA>