From nobody@FreeBSD.org  Mon Sep 19 14:23:43 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 09D5316A420
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 19 Sep 2005 14:23:43 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id AA3BE43D45
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 19 Sep 2005 14:23:42 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j8JENgqk071316
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 19 Sep 2005 14:23:42 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j8JENgtY071314;
	Mon, 19 Sep 2005 14:23:42 GMT
	(envelope-from nobody)
Message-Id: <200509191423.j8JENgtY071314@www.freebsd.org>
Date: Mon, 19 Sep 2005 14:23:42 GMT
From: Gleb Kozyrev <gkozyrev@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: LOR in kern/uipc_usrreq.c and kern/kern_descrip.c
X-Send-Pr-Version: www-2.3

>Number:         86336
>Category:       kern
>Synopsis:       [lor] LOR in kern/uipc_usrreq.c and kern/kern_descrip.c
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    rwatson
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 19 14:30:13 GMT 2005
>Closed-Date:    Sun Aug 03 16:16:29 UTC 2008
>Last-Modified:  Sun Aug 03 16:16:29 UTC 2008
>Originator:     Gleb Kozyrev
>Release:        FreeBSD 6.0-BETA4 i386
>Organization:
>Environment:
FreeBSD 6.0-BETA4 #0: Wed Sep 14 10:37:28 EEST 2005 ... GENERIC  i386
wine-20050830 and a multithreaded Windows application
>Description:
I was running Hamster Playground (http://www.elbiah.de/hamster/pg/) under Wine and saw this:

lock order reversal
 1st 0xc0971c60 unp (unp) @ /usr/src/sys/kern/uipc_usrreq.c:249
 2nd 0xc0922160 filelist lock (filelist lock) @ /usr/src/sys/kern/kern_descrip.c:2127
KDB: stack backtrace:
kdb_backtrace(0,ffffffff,c0934d08,c09346f0,c08c04cc) at kdb_backtrace+0x29
witness_checkorder(c0922160,9,c08571f2,84f) at witness_checkorder+0x564
_sx_xlock(c0922160,c08571f2,84f) at _sx_xlock+0x50
fdrop_locked(c1b41c60,0,c12f8f40,0,c08571f2) at fdrop_locked+0xa1
fdrop(c1b41c60,0,3,c15d8d80,cc8e69d4) at fdrop+0x24
closef(c1b41c60,0,c1703418,cc8e6a4c,c06762fc) at closef+0x35f
unp_discard(c1b41c60) at unp_discard+0x43
unp_scan(c1703400,c0676384) at unp_scan+0x80
unp_dispose(c1703400) at unp_dispose+0x15
sorflush(c20ac000,c20dac18,c20ac000,cc8e6b18,c067387e) at sorflush+0x119
unp_detach(c233c604,cc8e6b30,c066bb84,c20ac000,c20dac18) at unp_detach+0xc5
uipc_detach(c20ac000) at uipc_detach+0x4a
soclose(c20ac000,c20dac18,0,cc8e6b5c,c0617fb8) at soclose+0x1e0
soo_close(c20dac18,c15d8d80) at soo_close+0x4b
fdrop_locked(c20dac18,c15d8d80,c12f8ed4,0,c08571f2) at fdrop_locked+0x88
fdrop(c20dac18,c15d8d80,cc8e6ba8,c0654740,c08571f2) at fdrop+0x24
closef(c20dac18,c15d8d80) at closef+0x35f
fdfree(c15d8d80,c15fdb88,282754e4,c15d8d80,c0905500) at fdfree+0x473
exit1(c15d8d80,100,cc8e6d30,c07f22fb,c15d8d80) at exit1+0x3f6
exit1(c15d8d80,cc8e6d04,1,12b,292) at exit1
syscall(3b,3b,3b,8089200,bfbfe67c) at syscall+0x22f
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x281f3433, esp = 0xbfbfe2f0, ebp = 0xbfbfe30c ---
>How-To-Repeat:
No definite way. Try to run the mentioned application for some time.
>Fix:
      
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->rwatson 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Mon Sep 19 15:32:29 GMT 2005 
Responsible-Changed-Why:  
Grab ownership of this PR since it relates to the netperf project; I will 
have a chance to investigate in detail after 6.0-RELEASE.  Likely we 
should be running the GC step for file descriptors in transit in UNIX 
domain sockets in an asynchronous context from the actual closing of the 
initial descriptor.  The details are not yet clear. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=86336 

From: "Bjoern A. Zeeb" <bzeeb+freebsd+lor@zabbadoz.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/86336: LOR in kern/uipc_usrreq.c and kern/kern_descrip.c
Date: Mon, 19 Sep 2005 19:31:29 +0000 (UTC)

 For the archives. I have assigned LOR ID 161 to this one:
 see http://sources.zabbadoz.net/freebsd/lor.html#161
State-Changed-From-To: open->feedback 
State-Changed-By: rwatson 
State-Changed-When: Sun Jan 13 16:14:52 UTC 2008 
State-Changed-Why:  
This bug is believed to have been fixed in uipc_usrreq.c:1.159 and MFC'd 
as uipc_usrreq.c:1.155.2.2 to 6.x.  As such, the fix should have appeared 
in FreeBSD 6.1.  Can you confirm if the problem still exists in FreeBSD 
6.1 or later? 


http://www.freebsd.org/cgi/query-pr.cgi?pr=86336 
State-Changed-From-To: feedback->closed 
State-Changed-By: rwatson 
State-Changed-When: Sun Aug 3 16:15:54 UTC 2008 
State-Changed-Why:  
Feedback timeout; this problem is believed fixed.  If you are still able 
to reproduce it on recent FreeBSD versions, please follow up to the PR 
so that I can re-open it.  Thanks for the report! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=86336 
>Unformatted:
