kern/141695: [sctp] [panic] kernel page fault with non-sleepable lock sctp-inp held

[Bruce Cran]

>Number:         141695
>Category:       kern
>Synopsis:       [sctp] [panic] kernel page fault with non-sleepable lock sctp-inp held
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 17 03:20:00 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Bruce Cran
>Release:        9.0-CURRENT
>Organization:
>Environment:
FreeBSD tau.draftnet 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Dec 14 15:44:18 GMT 2009 brucec at tau.draftnet:/usr/obj/usr/src/sys/GENERIC amd64
>Description:
When running lots of copies (>100) of the SCTP API tester application 'api_tests' the following panic occurs:

Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex sctp-inp (inp) r = 0 (0xffffff011bb97960) locked @ /usr/src/sys/netinet/sctp_input.c:93
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_warn() at witness_warn+0x2c2
trap() at trap+0x2ce
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0xffffffff806c1cab, rsp = 0xffffff800003d420, rbp = 0xffffff800003d990 ---
sctp_process_control() at sctp_process_control+0x3eeb
sctp_common_input_processing() at sctp_common_input_processing+0x1b1
sctp_input_with_port() at sctp_input_with_port+0x388
ip_input() at ip_input+0xbc
swi_net() at swi_net+0x151
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop() at ithread_loop+0xb2
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff800003dd30, rbp = 0 ---

The same panic and stack trace also occurs with the sctp-tcb lock held from /usr/src/sys/netinet/sctp_pcb.c:1892

The message from sctp_pcb.c "This conflict in free SHOULD not be happening!" is also occasionally displayed, though the system doesn't panic at that point.
>How-To-Repeat:
Run a shell script containing around 100 copies of the command:

./api_tests > /dev/null &

It takes a minute or so of running the script, waiting for most of the api_test processes to quit then running the script again before the system panics.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: