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, e.g., https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076864.html). So, (1) I'm surprised you can boot it, and (2) that would explain why no one else has been using it. -BenReceived on Tue Nov 18 2014 - 21:39:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC