kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion "!cpu_softintr_p()" ... subr_kmem.c

[kardel%pip.acrys.com@localhost]

>Number:         41918
>Category:       kern
>Synopsis:       pppoe reconnects break with panic
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 22 11:40:00 +0000 2009
>Originator:     Frank Kardel
>Release:        NetBSD 5.99.15
>Organization:
        
>Environment:
        
        
System: NetBSD pip 5.99.15 NetBSD 5.99.15 (PIP) #0: Sat Aug 22 11:09:52 MEST 
2009 kardel@pip:/src/obj.i386/sys/arch/i386/compile/PIP i386
Architecture: i386
Machine: i386
>Description:
        pppoe reconnect reliably panic the kernel.
        hand copied stack trace (because of kern/41095 still being there):
        panic:kernel diagnostic assertion "!cpu_softintr_p()" failed: file 
".../sys/kern/subr_kmem.c", line 194
        kmem_alloc
        kmem_zalloc
        in6_ifattach
        in6_if_up
        sppp_lcp_tlu
        sppp_cp_input
        sppp_input
        pppoe_softintr_handler
        softint_dispatch

        The violation of calling kmem_zalloc() (likely in 
in6_ifaddrs_schedule()) from a softint seems clear. Possibly pppoe shouldn't 
call in6_ifattach from softint.
        Currently this leads to a reliable panic every 24h with german DSL 
providers that think forceful disconnection every 24h is a bright idea.
>How-To-Repeat:
        pick a -current (e. g. 20090822060000Z) kernel. fire up pppoe, let it 
connect, disconnect network cable, wait for lcp echo to time out (phase=dead), 
re-connect network cable, wait for reconnect via pppoe, enjoy panic.

>Fix:
        may change the way pppoe handles the re-connect.

>Unformatted: