[Bug 210684] LOR between so_snd_sx and ufs

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 210684
           Summary: LOR between so_snd_sx and ufs
           Product: Base System
           Version: 10.3-RELEASE
          Hardware: i386
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: ml at netfence.it
                CC: freebsd-i386 at FreeBSD.org
                CC: freebsd-i386 at FreeBSD.org

For reasons beyond the scope, I compiled a kernel with debug checks and got:

Jun 29 07:46:38 xxxxxx kernel: Starting winbindd.
Jun 29 07:46:38 xxxxxx winbindd[781]: [2016/06/29 07:46:38.915443,  0]
../source3/winbindd/winbindd_cache.c:3245(initialize_winbindd_cache)
Jun 29 07:46:38 xxxxxx kernel: Starting snmpd.
Jun 29 07:46:38 xxxxxx kernel: Jun 29 07:46:38 xxxxxx winbindd[781]:
[2016/06/29 07:46:38.915443,  0]
../source3/winbindd/winbindd_cache.c:3245(initialize_winbindd_cache)
Jun 29 07:46:38 xxxxxx winbindd[781]:   initialize_winbindd_cache: clearing
cache and re-creating with version number 2
Jun 29 07:46:38 xxxxxx kernel: Jun 29 07:46:38 xxxxxx winbindd[781]:  
initialize_winbindd_cache: clearing cache and re-creating with version number 2
Jun 29 07:46:39 xxxxxx winbindd[781]: [2016/06/29 07:46:39.197239,  0]
../lib/util/become_daemon.c:124(daemon_ready)
Jun 29 07:46:39 xxxxxx kernel: Jun 29 07:46:39 xxxxxx winbindd[781]:
[2016/06/29 07:46:39.197239,  0] ../lib/util/become_daemon.c:124(daemon_ready)
Jun 29 07:46:39 xxxxxx winbindd[781]:   STATUS=daemon 'winbindd' finished
starting up and ready to serve connections
Jun 29 07:46:39 xxxxxx kernel: Jun 29 07:46:39 xxxxxx winbindd[781]:  
STATUS=daemon 'winbindd' finished starting up and ready to serve connections
Jun 29 07:46:40 xxxxxx kernel: lock order reversal:
Jun 29 07:46:40 xxxxxx kernel: 1st 0xce58eb14 so_snd_sx (so_snd_sx) @
/usr/src/sys/kern/uipc_sockbuf.c:148
Jun 29 07:46:40 xxxxxx kernel: 2nd 0xce2b0150 ufs (ufs) @
/usr/src/sys/kern/vfs_lookup.c:509
Jun 29 07:46:40 xxxxxx kernel: KDB: stack backtrace:
Jun 29 07:46:40 xxxxxx kernel:
db_trace_self_wrapper(c0a1efd8,3834313a,ce2a000a,ce2af838,a1,...) at
db_trace_self_wrapper+0x2d/frame 0xf853c4f8
Jun 29 07:46:40 xxxxxx kernel:
kdb_backtrace(c0a231d4,ce2b0150,c0a0ed4d,cd7bfb08,c0a2be9c,...) at
kdb_backtrace+0x30/frame 0xf853c55c
Jun 29 07:46:40 xxxxxx kernel:
witness_checkorder(ce2b0150,1,c0a2be9c,1fd,0,...) at
witness_checkorder+0xd4f/frame 0xf853c5a8
Jun 29 07:46:40 xxxxxx kernel: __lockmgr_args(ce2b0150,202400,ce2b0170,0,0,...)
at __lockmgr_args+0x4b8/frame 0xf853c688
Jun 29 07:46:40 xxxxxx kernel:
ffs_lock(f853c708,c0b7fcf0,c0cab8b8,c0aa6708,cd7b6248,...) at
ffs_lock+0x94/frame 0xf853c6c4
Jun 29 07:46:40 xxxxxx kernel:
VOP_LOCK1_APV(c0abc8f0,f853c708,200246,9cb,c0ad43f8,...) at
VOP_LOCK1_APV+0x10a/frame 0xf853c6f0
Jun 29 07:46:40 xxxxxx kernel: _vn_lock(ce2b011c,202400,c0a2be9c,1fd,0,...) at
_vn_lock+0xca/frame 0xf853c730
Jun 29 07:46:40 xxxxxx kernel: lookup(f853c888,c0a2be9c,110,d5,ce34a280,...) at
lookup+0xf5/frame 0xf853c790
Jun 29 07:46:40 xxxxxx kernel: namei(f853c888,0,144,1,f853c929,...) at
namei+0x48d/frame 0xf853c828
Jun 29 07:46:40 xxxxxx kernel:
unp_connectat(ce270300,cde9f960,c0a29331,364,f853cb50,...) at
unp_connectat+0x1e9/frame 0xf853ca3c
Jun 29 07:46:40 xxxxxx kernel: uipc_send(ce58e9f0,0,ce877700,ce270300,0,...) at
uipc_send+0x5a1/frame 0xf853ca90
Jun 29 07:46:40 xxxxxx kernel:
sosend_generic(ce58e9f0,ce270300,f853cb50,0,0,...) at
sosend_generic+0x3c9/frame 0xf853cb08
Jun 29 07:46:40 xxxxxx kernel: kern_sendit(cde9f960,6,f853cbe8,0,0,...) at
kern_sendit+0x207/frame 0xf853cb88
Jun 29 07:46:40 xxxxxx kernel: sendit(f853cbe8,0,f853cbe4,28,ce1a6918,...) at
sendit+0x11d/frame 0xf853cbc8
Jun 29 07:46:40 xxxxxx kernel:
sys_sendmsg(cde9f960,f853cca8,ce1a6918,f853cc70,c098ee18,...) at
sys_sendmsg+0x79/frame 0xf853cc18
Jun 29 07:46:40 xxxxxx kernel: syscall(f853cce8) at syscall+0x381/frame
0xf853ccdc
Jun 29 07:46:40 xxxxxx kernel: Xint0x80_syscall() at
Xint0x80_syscall+0x2f/frame 0xf853ccdc
Jun 29 07:46:40 xxxxxx kernel: --- syscall (28, FreeBSD ELF32, sys_sendmsg),
eip = 0x22867abf, esp = 0xbfbfc688, ebp = 0xbfbfc6a4 ---
Jun 29 07:46:41 xxxxxx kernel: Starting smartd.

The box did not panic or enter the debugger, so I'm not sure how severe is
this, but AFAICT it hasn't been reported yet.

In case it matters, the box is an NFS client with two GMIRRORed SCSI disks.

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