arm/188933: lock order reversal: backtrace while writing to SD/eMMC

[Winston Smith]

The following reply was made to PR arm/188933; it has been noted by GNATS.

From: Winston Smith <smith.winston.101 at gmail.com>
To: bug-followup at FreeBSD.org
Cc:  
Subject: Re: arm/188933: lock order reversal: backtrace while writing to SD/eMMC
Date: Thu, 24 Apr 2014 08:47:59 -0400

 I found the exact same issue testing on FreeBSD-CURRENT on the BBB;
 this was removing a directory tree with `rm -rf` on the eMMC:
 
 
 FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r264670: Fri
 Apr 18 18:55:02 EDT 2014
 root at freebsd:/root/Work/crochet-freebsd/work/obj/arm.armv6/usr/src/FreeBSD-CURRENT/sys/BEAGLEBONE
  arm
 
 
 
 lock order reversal:
  1st 0xcd25b0f8 bufwait (bufwait) @
 /usr/src/FreeBSD-CURRENT/sys/kern/vfs_bio.c:3081
  2nd 0xc3260600 dirhash (dirhash) @
 /usr/src/FreeBSD-CURRENT/sys/ufs/ufs/ufs_dirhash.c:284
 KDB: stack backtrace:
 db_trace_self() at db_trace_self
      pc = 0xc0542258  lr = 0xc02324bc (db_trace_self_wrapper+0x30)
      sp = 0xde6c89e0  fp = 0xde6c8af8
     r10 = 0xc3260600
 db_trace_self_wrapper() at db_trace_self_wrapper+0x30
      pc = 0xc02324bc  lr = 0xc039b358 (kdb_backtrace+0x38)
      sp = 0xde6c8b00  fp = 0xde6c8b08
      r4 = 0xc0689484  r5 = 0xc059401b
      r6 = 0xc05c7b91  r7 = 0xc05b16e0
 kdb_backtrace() at kdb_backtrace+0x38
      pc = 0xc039b358  lr = 0xc03b5c78 (witness_checkorder+0xe50)
      sp = 0xde6c8b10  fp = 0xde6c8b60
      r4 = 0xc05c7f53
 witness_checkorder() at witness_checkorder+0xe50
      pc = 0xc03b5c78  lr = 0xc036c1bc (_sx_xlock+0x7c)
      sp = 0xde6c8b68  fp = 0xde6c8b90
      r4 = 0x0000011c  r5 = 0xc05c7b8e
      r6 = 0xc3260610  r7 = 0xc3260600
      r8 = 0x00000000  r9 = 0xc31a3280
     r10 = 0x00000000
 _sx_xlock() at _sx_xlock+0x7c
      pc = 0xc036c1bc  lr = 0xc04fe408 (ufsdirhash_remove+0x38)
      sp = 0xde6c8b98  fp = 0xde6c8bb0
      r4 = 0xc3260600  r5 = 0xc31a024c
      r6 = 0xce430018  r7 = 0xc31a3280
      r8 = 0x00000018
 ufsdirhash_remove() at ufsdirhash_remove+0x38
      pc = 0xc04fe408  lr = 0xc0501260 (ufs_dirremove+0x14c)
      sp = 0xde6c8bb8  fp = 0xde6c8be8
      r4 = 0xc3048c00  r5 = 0xc31a024c
      r6 = 0xc31a0240  r7 = 0xce430018
      r8 = 0x00000000
 ufs_dirremove() at ufs_dirremove+0x14c
      pc = 0xc0501260  lr = 0xc05076e8 (ufs_remove+0x64)
      sp = 0xde6c8bf0  fp = 0xde6c8c18
      r4 = 0xc3041d80  r5 = 0x00000001
      r6 = 0xc31a0240  r7 = 0xc3048c00
      r8 = 0xc2e05000  r9 = 0xc3041d80
     r10 = 0x00000000
 ufs_remove() at ufs_remove+0x64
      pc = 0xc05076e8  lr = 0xc056bd5c (VOP_REMOVE_APV+0xd0)
      sp = 0xde6c8c20  fp = 0xde6c8c30
      r4 = 0xde6c8d78  r5 = 0xc066acd0
      r6 = 0x00000000  r7 = 0xffffff9c
      r8 = 0x00000000
 VOP_REMOVE_APV() at VOP_REMOVE_APV+0xd0
      pc = 0xc056bd5c  lr = 0xc04126dc (kern_unlinkat+0x1b4)
      sp = 0xde6c8c38  fp = 0xde6c8da8
      r4 = 0xde6c8cd8  r5 = 0xc2e05000
      r6 = 0x2081b358
 kern_unlinkat() at kern_unlinkat+0x1b4
      pc = 0xc04126dc  lr = 0xc04122fc (sys_unlink+0x24)
      sp = 0xde6c8db0  fp = 0xde6c8db8
      r4 = 0xc2e05000  r5 = 0xc2dfb640
      r6 = 0x00000000  r7 = 0x00000000
      r8 = 0x00000001  r9 = 0xde6c8e10
     r10 = 0x00012790
 sys_unlink() at sys_unlink+0x24
      pc = 0xc04122fc  lr = 0xc0557878 (swi_handler+0x284)
      sp = 0xde6c8dc0  fp = 0xde6c8e58
 swi_handler() at swi_handler+0x284
      pc = 0xc0557878  lr = 0xc0543d74 (swi_exit)
      sp = 0xde6c8e60  fp = 0xbffffce0
      r4 = 0x20803080  r5 = 0x0000a4ce
      r6 = 0x00000000  r7 = 0x0000000a
      r8 = 0x00000001  r9 = 0x00000000
 swi_exit() at swi_exit
      pc = 0xc0543d74  lr = 0xc0543d74 (swi_exit)
      sp = 0xde6c8e60  fp = 0xbffffce0
 Unable to unwind further