Re: WITNESS observes 2 LORs on Boot of Release 10.1

On Fri, 21 Nov 2014, Ellis H. Wilson III wrote:

> Before I start, and this is mainly geared to my responder Benjamin Kaduk,
> based on your response, are you suggesting that the cnputc WITNESS panic you
> expected to happen is now completely unavoidable in FreeBSD 10?  I.E., is this
> a spinlock that WITNESS falls over each time but that is provably deadlock
> free that the developers have decided cannot be BLESSED for some reason?

https://lists.freebsd.org/pipermail/freebsd-current/2012-January/031316.html
looks to be a better explanation than the previous link I sent ... in
short, console output is hard.

> I guess I just can't wrap my head around why we would ever move to a regime
> where SKIPSPIN is the default for testing...  That just seems like an open
> invitation for introducing spinlock regressions.

I don't think anyone made the conscious decision to do that, it just
happened by default as no one spent the time to fix the aforementioned
issue.

> Moving onto the LORs I'm seeing, a question I have as a newbie to WITNESS
> debugging is how exactly to interpret the output if I see a stacktrace and
> then a LOR output like the following:
>
> lock order reversal:
>   1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) _at_
> /usr/src/sys/dev/random/random_harvestq.c:198
>   2nd 0xffffffff813b6208 scrlock (scrlock) _at_
> /usr/src/sys/dev/syscons/syscons.c:2682
>
> Does this mean WITNESS has already stored an ordering of #1 harvest_mtx then
> #2 scp->scr_lock, and somewhere somebody tried to lock scp->scr_lock without
> first getting harvest_mtx?  Or the reverse (WITNESS previously recorded
> scrlock and then harvest and the lines it spit out were the offenders?)

I believe it is the latter (the ordering being printed is the bad one
which caused WITNESS to complain).

-Ben