The following reply was made to PR kern/30154; it has been noted by GNATS.

From: "Alexey G. Khramkov" <agkhram@mercdev.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/30154: tcp_close locking botch
Date: Sat, 07 May 2005 15:17:05 +0500

 yamt@mwd.biglobe.ne.jp writes:
 
 >>Number:         30154
 >>Category:       kern
 >>Synopsis:       tcp_close locking botch
 >>Confidential:   no
 >>Severity:       serious
 >>Priority:       medium
 >>Responsible:    kern-bug-people
 >>State:          open
 >>Class:          sw-bug
 >>Submitter-Id:   net
 >>Arrival-Date:   Fri May 06 14:15:00 +0000 2005
 >>Originator:     YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
 >>Release:        NetBSD 3.99.3
 >>Organization:
 >
 >>Environment:
 > 	
 > 	
 > System: NetBSD kaeru 3.99.3 NetBSD 3.99.3 (build.kaeru.xen) #78: Wed May 4 23:21:47 JST 2005 takashi@kaeru:/home/takashi/work/kernel/build.kaeru.xen i386
 
 My system is GENERIC.MP, CVSed May 3 or 4.
 
 > Architecture: i386
 > Machine: i386
 >>Description:
 > 	tcp_close can be called from interrupt context.
 > 	however, it isn't safe.
 >
 > 	eg. tcp_input -> tcp_close -> in_pcbdetach
 > 	    -> sofree -> chgsbsize -> uid_find
 >>How-To-Repeat:
 > 	code inspection.
 
 Router, ftp, web, nat server.
 
 Just wait from 30 min till 2 days uptime. No panic, just hangs.
 It needs hard reset.
 
 Excerpt from ddb:
 simple_lock: locking against myself
 lock:0xc07ff628 currently at kern_resource.c:907 on CPU 1
 last locked: kern_resource.c:904
 last unlocked: kern_resource.c:907
 
 and backtrace is the same as mentioned above.
 
 >>Fix:
 > 	
 >
 >>Unformatted:
 >  	
 >  	
 >
 >
 
 -- 
 = Alexey G. Khramkov (agkhram) @ Infotech <agkhram{at}mercdev{dot}com> =
 = GPG fingerprint : 944D 0C8B 343B 6C8D 50A1  061A E2DA 3E11 7765 6B47 =