Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Jan 2007 14:26:35 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-current@freebsd.org
Cc:        Craig Rodrigues <rodrigc@crodrigues.org>, Randall Stewart <rrs@cisco.com>, Robert Watson <rwatson@freebsd.org>
Subject:   Re: Witness warning with SCTP
Message-ID:  <200701091426.36740.jhb@freebsd.org>
In-Reply-To: <20070107185228.W41371@fledge.watson.org>
References:  <20070107171034.GA13836@crodrigues.org> <45A139CF.3090909@cisco.com> <20070107185228.W41371@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 07 January 2007 13:54, Robert Watson wrote:
> On Sun, 7 Jan 2007, Randall Stewart wrote:
> 
> > Craig:
> >
> > When we allocate a PCB we hold several locks. This prevents a conflict of 
> > say a sender allocating a PCB at the very same instant (this was one of my 
> > race condition bugs that was fixed recently).
> >
> > Now, each PCB has a small hash table it uses. We call hashinit() for 
this ..
> >
> > hashinit() does a malloc with M_WAITOK
> >
> > thus the warning.
> >
> > So, I either need to make another hashinit() function with a passed flag 
for 
> > the wait (seems the best way) OR make a sctp specific hashinit.. which I 
> > don't like doing..
> >
> > Maybe I can change the name of hashinit() to hashinit_x() and then make 
> > hashinit() be a macro that calls hasinit_x with M_WAITOK.. then I could 
use 
> > hashinit_x() directly?
> >
> > Don't know what the best course is to go here...
> >
> > It is rather strange that I have not seen this, since like I said one of 
my 
> > machines is running with witness enabled .. hmm..
> >
> > Anyway.. advice from others how I should proceed would be welcome..
> >
> > hashinit_x() or an sctp specific hash_init??
> 
> I think my preference would be to see a hashinit_flags() or the like, and 
have 
> a wait argument to that.  I'd be tempted to give it a new name, like 
> HASH_WAITOK or such, in case we want to add other flags in the future.
> 
> Remember to update hashinit(9). :-)

Either that or use an sx lock to close the pcb alloc race instead and don't 
hold mutexes while calling hashinit().

> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> 
> >
> > R
> >
> > Craig Rodrigues wrote:
> >> Hi,
> >> 
> >> I am running one of the SCTP tests in the ACE library,
> >> and am getting the following witness warning.  Any ideas what the cause
> >> is?
> >> 
> >> Thanks.
> >> 
> >> malloc(M_WAITOK) of "1024", forcing M_NOWAIT with the following 
> >> non-sleepable locks held:
> >> exclusive sleep mutex sctp-create (inp_create) r = 0 (0xc2ddded0) locked 
@ 
> >> /usr/src/sys/netinet/sctp_input.c:4006
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper(c09bf21a) at db_trace_self_wrapper+0x25
> >> kdb_backtrace(1,400,c146d5a0,6,cbd70148,...) at kdb_backtrace+0x29
> >> witness_warn(5,0,c09dac6c,c09701c9) at witness_warn+0x192
> >> uma_zalloc_arg(c146d5a0,0,2) at uma_zalloc_arg+0x41
> >> malloc(400,c0a50840,2,c28cf3e4,cbd701ac,...) at malloc+0xb2
> >> hashinit(100,c0a50840,c2dde80c,f1,c28cf3e4,...) at hashinit+0x3b
> >> sctp_inpcb_alloc(c28cf3e4) at sctp_inpcb_alloc+0x143
> >> sctp_attach(c28cf3e4,0,0) at sctp_attach+0x34
> >> sonewconn(c28a9530,2,c2ddff48,0,c09cf2c5,839) at sonewconn+0x119
> >> 
sctp_handle_cookie_echo(c297e900,14,20,c297e948,cbd70390,cbd70bbc,cbd70bc0,cbd70c20,0,0,0,cbd70384) 
> >> at sctp_handle_cookie_echo+0x77e
> >> 
sctp_process_control(c297e900,14,cbd70c08,1ac,c297e948,c297e954,c2dddc10,c2ddfa50,cbd70c20,cbd70be8) 
> >> at sctp_process_control+0xd89
> >> 
sctp_common_input_processing(cbd70c3c,14,20,1ac,c297e948,c297e954,c2dddc10,0,c2de1570,0) 
> >> at sctp_common_input_processing+0x72
> >> sctp_input(c297e900,14,ae,100007f,0,...) at sctp_input+0x2fa
> >> ip_input(c297e900) at ip_input+0x5c5
> >> netisr_processqueue(c0af3658) at netisr_processqueue+0x6e
> >> swi_net(0) at swi_net+0xc2
> >> ithread_execute_handlers(c210b6c0,c2129900) at 
> >> ithread_execute_handlers+0x11e
> >> ithread_loop(c20ed960,cbd70d38) at ithread_loop+0x67
> >> fork_exit(c06bbd2c,c20ed960,cbd70d38) at fork_exit+0xac
> >> fork_trampoline() at fork_trampoline+0x8
> >> 
> >
> >
> > -- 
> > Randall Stewart
> > NSSTG - Cisco Systems Inc.
> > 803-345-0369 <or> 803-317-4952 (cell)
> > _______________________________________________
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
> >
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
> 

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200701091426.36740.jhb>