Problem remains with FreeBSD 6.0-RC1 as seen in RELENG_5

[Robert Watson]

On Tue, 25 Oct 2005, Philip Kizer wrote:

> On Oct 19, 2005, at 11:54, Robert Watson wrote:
>> This appears to be a problem with file descriptor passing and garbage 
>> collection.  I've seen one report of a lock order reversal along these 
>> lines, but it was not believed to be symptomatic of an actual hang, just an 
>> architectural issue.  This could be a sign that we need to address the 
>> source of the reversal, although it sounds like you don't get a reversal
>> warning?
>> 
>> Could I have you try the following DDB commands also:
>> 
>>   show alllocks
>>   traceall
>
> OK, this is a new hang with almost all I had before (looks like I did 
> forgot the "print sysctllock", will I need to be sure and include it for 
> a complete diagnosis?) and those two as well:
>
>  http://www.nostrum.com/hang/hang.trace-2005-10-25-0.txt
>
> [Or would you prefer I include it directly rather than sparing the list 
> the output?]

URL is fine, and useful, thanks!

There are a couple of possible sources, so if this is reproduceable and 
you don't mind trying some diagnostic patches, I've attached a first one 
below.  This checks for the case where the looping in the unp_gc() routine 
becomes unbounded due to a possible lack of synchronization in the 
handling of marking and counting of marking.  It needs INVARIANTS to be 
compiled in to work; if it fires, this will suggest an avenue to explore.

Robert N M Watson

Index: uipc_usrreq.c
===================================================================
RCS file: /data/fbsd-cvs/ncvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.156
diff -u -r1.156 uipc_usrreq.c
--- uipc_usrreq.c	23 Sep 2005 12:41:06 -0000	1.156
+++ uipc_usrreq.c	25 Oct 2005 10:04:36 -0000
@@ -1613,6 +1613,7 @@
  	LIST_FOREACH(fp, &filehead, f_list)
  		fp->f_gcflag &= ~(FMARK|FDEFER);
  	do {
+		KASSERT(unp_defer >= 0, ("unp_gc: unp_defer %d", unp_defer));
  		LIST_FOREACH(fp, &filehead, f_list) {
  			FILE_LOCK(fp);
  			/*