Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Nov 2012 12:55:10 -0700
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        attilio@FreeBSD.org
Cc:        freebsd-hackers@FreeBSD.org, Adrian Chadd <adrian@FreeBSD.org>, freebsd-arch@FreeBSD.org
Subject:   Re: [RFQ] make witness panic an option
Message-ID:  <1353009310.1217.172.camel@revolution.hippie.lan>
In-Reply-To: <CAJ-FndBP5Pi=SCpyBLK3b=HM_gQ9u8M4%2B1tLk9tA5X-gqismVA@mail.gmail.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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2012-11-15 at 17:47 +0000, 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?
> 

No. 

Since you've made it abundantly clear in this thread that you are not
open to anyone else's opinion and won't change your mind, I'm not going
to waste even 10 seconds explaining my perfectly valid needs.

I'll just keep hacking the code up to not panic when I need to.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1353009310.1217.172.camel>