[Bug 195262] New: [lor] Possibly two LORs: entropy harvest mutex and scrlock, and entropy harvest mutex and sleepq chain

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195262

            Bug ID: 195262
           Summary: [lor] Possibly two LORs: entropy harvest mutex and
                    scrlock, and entropy harvest mutex and sleepq chain
           Product: Base System
           Version: 10.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: Needs Triage
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: ellisw at panasas.com

I get the following output from WITNESS detecting a LOR for possibly two LORs
relating to the harvest mutex on bootup.  This is an almost perfectly standard
boot of 10.1-RELEASE with the exception that I've enabled WITNESS.  Please note
that I have NOT enabled WITNESS_SKIPSPIN.  That seems to be the widely accepted
band-aid for issues that look like this.  Such a solution, if you can call it
such, is not acceptable at my company.  I'm happy to do the fix for this bug,
but I wanted to open this at least so it's on people's radars, and to solicit
feedback from the community if this is an absolutely unavoidable LOR (and why
we can't just mark the lock BLESSED if so).

Selected output from my VM running 10.1 with WITNESS:

<snip>
 atrtc0: <AT realtime clock> at port 0x70 irq 8 on isa0
 Event timer "RTC" frequency 32768 Hz quality 0
 ppc0: cannot reserve I/O port range
 Timecounters tick every 10.000 msec
 pcm0: measured ac97 link rate at 30976 Hz
 lock order reversal:
 lock order reversal:
  1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @
/usr/src/sys/dev/random/random_harvestq.c:198
  2nd 0xffffffff813b6208 scrlock (scrlock) @
/usr/src/sys/dev/syscons/syscons.c:2682
 KDB: stack backtrace:
 #0 0xffffffff808b6c40 at kdb_backtrace+0x60
#1 0xffffffff808ca56a at witness_checkorder+0xb8a
#2 0xffffffff808714ae at __mtx_lock_spin_flags+0x4e
#3 0xffffffff806db7d0 at sc_puts+0xb0
#4 0xffffffff806dee55 at sc_cnputc+0xe5
#5 0xffffffff80842c7f at cnputc+0x7f
#6 0xffffffff80842f18 at cnputs+0x58
#7 0xffffffff808bba57 at putchar+0x137
#8 0xffffffff808ba7ea at kvprintf+0xda
#9 0xffffffff808bc057 at vprintf+0x87
#10 0xffffffff808bbfc3 at printf+0x43
#11 0xffffffff808ca35e at witness_checkorder+0x97e
#12 0xffffffff808714ae at __mtx_lock_spin_flags+0x4e
#13 0xffffffff8088a29b at msleep_spin_sbt+0x5b
#14 0xffffffff8063f0b8 at random_kthread+0x78
#15 0xffffffff80858b11 at fork_exit+0x71
#16 0xffffffff80c2143e at fork_trampoline+0xe
 1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @
/usr/src/sys/dev/random/random_harvestq.c:198
 2nd 0xffffffff81424bb8 sleepq chain (sleepq chain) @
/usr/src/sys/kern/subr_sleepqueue.c:240
KDB: stack backtrace:
#0 0xffffffff808b6c40 at kdb_backtrace+0x60
#1 0xffffffff808ca56a at witness_checkorder+0xb8a
#2 0xffffffff808714ae at __mtx_lock_spin_flags+0x4e
#3 0xffffffff8088a29b at msleep_spin_sbt+0x5b
#4 0xffffffff8063f0b8 at random_kthread+0x78
#5 0xffffffff80858b11 at fork_exit+0x71
#6 0xffffffff80c2143e at fork_trampoline+0xe
usbus0: 12Mbps Full Speed USB v1.0
ugen0.1: <Apple> at usbus0
uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: <VBOX HARDDISK 1.0> ATA-6 device
ada0: Serial Number VB96c35aac-e62dbb5d
ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes)
ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad0
<snip> 

I have it panicking into DDB now, so if there are suggestions on best
strategies for tackling LORs I'm all ears.

-- 
You are receiving this mail because:
You are the assignee for the bug.