Bug 210684 - LOR between so_snd_sx and ufs
Summary: LOR between so_snd_sx and ufs
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.3-RELEASE
Hardware: i386 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-29 07:00 UTC by ml
Modified: 2022-01-22 16:45 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ml 2016-06-29 07:00:47 UTC
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.