re: kern/44418 (FAST_IPSEC and if_wm kernel panic - may affect the whole network stack)

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR kern/44418; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: M.Drochner%fz-juelich.de@localhost
Cc: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>,
    gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
    gnats-admin%netbsd.org@localhost, Mindaugas Rasiukevicius 
<rmind%netbsd.org@localhost>
Subject: re: kern/44418 (FAST_IPSEC and if_wm kernel panic - may affect the 
whole network stack)
Date: Sun, 20 Feb 2011 01:34:35 +1100

 > rmind%netbsd.org@localhost said:
 > > Not sure what do you mean by "second time"
 > > [...]
 > > Recursive locking is
 > > deliberately prohibited in our mutex(9) implementation
 > > [...]
 > > Talking about limited softintr thread context
 > 
 > What I did suspect here is that some kernel code takes softnet_lock
 > without a splsoftnet() before, and a softnet handler gets to run
 > and happens to borrow the same thread context. In that case,
 > the diagnostic check could fire even if the softnet handler
 > doesn't do anything wrong.
 > Can this happen?
 
 in sparc smp land, where we've only recently started being stable
 again, the last 2 crashes i've seen were softnet_lock issues.
 i don't have the details handy, but it invovled slowtimo processing
 and softnet_lock being re-taken on the same CPU.
 
 i've wondered the same thing r.e. splsoftnet.
 
 
 .mrg.