From owner-freebsd-current@FreeBSD.ORG Fri Jun 18 23:01:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9C9A16A4CE for ; Fri, 18 Jun 2004 23:01:12 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 290A543D41 for ; Fri, 18 Jun 2004 23:01:12 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5IMwsSQ084691; Fri, 18 Jun 2004 18:58:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5IMwsl1084688; Fri, 18 Jun 2004 18:58:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 18 Jun 2004 18:58:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Grover Lines In-Reply-To: <20040618221256.09E1343D48@mx1.FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Stack backtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 23:01:12 -0000 On Fri, 18 Jun 2004, Grover Lines wrote: > I was reinstalling cvsup when the backtraces occurred. It caused a few > but it seems it keeps doing them after it was done installing. Iv'e > attached my Verbose dmesg and a part of my message log with the errors. I've committed a change that may well remove the source of the warning. It's revealed a weakness in some of the older TCP/IP protocol locking that I will work to remedy in the next couple of days. It shouldn't affect anything since Giant remains on by default in CVS over that part of the stack. If you could update and see if it's fixed, that would be great, thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research > > Sorry it took so long to get back to you > > > > On Fri, 18 Jun 2004, Grover Lines wrote: > > > > > I've been having some problems with cvsup corruption and haven't > > > been able to trace it to the source so I decided to recompile my > > > kernel with all GENERIC options and debugging to see if it was > > > something that I had changed that caused the problem. I'm not sure > > > what this means but it popped up during the build of cvsup. > > > > > > Is this a possible source of my problem or is this something not to > > > worry about? > > > > This is unlikely to be the cause of the problem you're experiencing, > > but it's also not something to be ignored. Basically, we're grabbing > > the inpcb lock over a potentially blocking memory allocation, which is > > a Bad Thing (tm). However, it's a non-trivial fix because it requires > > some code plumbing. I'll work up a patch and see what I can do, but > > it sounds like you need to keep looking to find the problem that's > > actually causing it. > > Also, do you have any idea what application it was you used that triggered > this message? > > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > robert@fledge.watson.org Senior Research Scientist, McAfee Research > > > > > > > > > > malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following > > > non-sleepable locks held: > > > exclusive sleep mutex inp (tcpinp) r = 0 (0xc1d17bd0) locked @ > > > /usr/src/sys/netinet/tcp_usrreq.c:1037 > > > Stack backtrace: > > > witness_warn(5,0,c08db91d,c08c1095,c08c5805) at witness_warn+0x194 > > > uma_zalloc_arg(c1021b00,d6b19c0c,2,c066635e,0) at > > > uma_zalloc_arg+0x50 > > > ip_ctloutput(c284213c,d6b19cb8,c08ce5cb,40e,c1d17bd0) at > > > ip_ctloutput+0x9b > > > tcp_ctloutput(c284213c,d6b19cb8,0,0,0) at tcp_ctloutput+0xad > > > sosetopt(c284213c,d6b19cb8,d6b19cb4,0,c284213c) at sosetopt+0x48 > > > setsockopt(c1d4ddc0,d6b19d14,14,d6b19d48,5) at setsockopt+0xd4 > > > syscall(2f,2f,2f,281a6920,3) at syscall+0x12f > > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > --- syscall (105), eip = 0x28108fef, esp = 0xbfbfe91c, ebp = > > > 0xbfbfe948 --- >