On Tue, 18 Nov 2014, Ellis H. Wilson III wrote:

> This is on a virtual machine via VirtualBox, but we have reproduced it on real
> hardware.  Regarding the latter reversal, I have dug in the code and see the
> calls go about in the following order:
> In sys/dev/random/random_harvestq.c:
>  198 mtx_lock_spin(&harvest_mtx);
>  209 msleep_spin_sbt(&random_kthread_control, &harvest_mtx,
> Now in sys/kern/kern_synch.c:
>  297 sleepq_lock(ident);
> Now in sys/kern/subr_sleepqueue.c
>  237 mtx_lock_spin(&sc->sc_lock);
> The above line numbers might be a hair off from head since I'm looking at code
> synced last week.
> I'm happy to open a bug on this if that's the desirable course of action, or
> to even assist in fixing it, but I wanted to first see if anybody knew about
> these already (they didn't show up on the known LORs list on quick perusal) or
> if this was simply a case of WITNESS being overly conservative and throwing
> false positives.  If this belongs on a different list just let me know.

I don't believe it is known, and this list is fine.

> I'm observing the following two WITNESS LORs being thrown upon boot-up of 10.0
> and I was tracking current, hoping they would go away by 10.1, but it seems
> they persist as shown below.  I suspect this is because current is being built
> with WITNESS on but also with SKIPSPIN on.  So these issues are unlikely to
> show up for any devs but those who specifically enable WITNESS and disable
> SKIPSPIN like myself.  At my work we would greatly like to do our debugging
> with checking of spin-locking order included and panicing upon LOR detection.
> That's not possible with these in existence.

However, I was under the impression that a kernel built with WITNESS and
without WITNESS_SKIPSPIN would panic on boot on the cnputs_mutx (see,
So, (1) I'm surprised you can boot it, and (2) that would explain why no
one else has been using it.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to