Re: Stack backtrace

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_at_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_at_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 _at_
> > > /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 ---
>