Re: LOR: /sys/ufs/ffs/ffs_snapshot.c:1893 /sys/vm/vm_map.c:2206

Pawel Jakub Dawidek <pjd_at_FreeBSD.org> wrote:
> Known?
> 
> lock order reversal
>  1st 0xc63b811c vnode interlock (vnode interlock) _at_ /mnt/perf/src/sys/ufs/ffs/ffs_snapshot.c:1893
>  2nd 0xc1039118 system map (system map) _at_ /mnt/perf/src/sys/vm/vm_map.c:2206
> Stack backtrace:
> backtrace(0,ffffffff,c0708c10,c0709ac0,c0608320) at backtrace+0x12
> witness_checkorder(c1039118,9,c05eed2c,89e) at witness_checkorder+0x593
> _mtx_lock_flags(c1039118,0,c05eed2c,89e) at _mtx_lock_flags+0x68
> _vm_map_lock(c10390b8,c05eed2c,89e) at _vm_map_lock+0x21
> vm_map_remove(c10390b8,c6727000,c6729000,e72b29ec,c0572341) at vm_map_remove+0x1f
> kmem_free(c10390b8,c6727000,2000,e72b2a04,c05738b7) at kmem_free+0x25
> page_free(c6727000,2000,22,c0616380,e72b2a28) at page_free+0x31
> uma_large_free(c63d3f54) at uma_large_free+0x7b
> free(c6727000,c0616380,c66e1100,a,c636d000) at free+0xfc
> ffs_snapshot_unmount(c636d000) at ffs_snapshot_unmount+0xe7
> ffs_flushfiles(c636d000,4,c666cbd0) at ffs_flushfiles+0x3b
> softdep_flushfiles(c636d000,4,c666cbd0,c636fb00,0) at softdep_flushfiles+0x1e
> ffs_mount(c636d000,c669a900,bfbfdf90,e72b2bf4,c666cbd0) at ffs_mount+0x1c7
> vfs_domount(c666cbd0,c61c6c60,c669a900,10001,bfbfdf90) at vfs_domount+0x6e6
> mount(c666cbd0,e72b2d14,4,0,202) at mount+0x6c
> syscall(2f,2f,2f,bfbfdf8c,2) at syscall+0x217
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (21), eip = 0x280c0f4f, esp = 0xbfbfdf6c, ebp = 0xbfbfe018 ---

I haven't seen it myself, but it seems like it's only going to happen 
sometimes (when a full page is freed).  There's really no technical reason 
you'd ever want to do a free(9) with locks held, so I suggest fixing it in 
the straightforward way.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green_at_FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\