Re: Witness warning with SCTP

From: Randall Stewart <rrs_at_cisco.com>
Date: Sun, 07 Jan 2007 13:19:59 -0500
Craig:

Ok, I know what this is..

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??

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 _at_ /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)
Received on Sun Jan 07 2007 - 17:20:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC