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

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

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

From: Mindaugas Rasiukevicius <rmind%netbsd.org@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>
Subject: Re: kern/44418 (FAST_IPSEC and if_wm kernel panic - may affect the
  whole network stack)
Date: Sat, 19 Feb 2011 03:52:18 +0000

 Matthias Drochner <M.Drochner%fz-juelich.de@localhost> wrote:
 > > 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?
 
 While soft-interrupt borrows a current thread context - it has a separate
 identity, that is, own 'curlwp' value.  Therefore, softint would block on
 the lock, return execution to the interrupted LWP, and when the lock gets
 released - soft-interrupt would continue.  In other words - that is not a
 condition of recursive lock attempt.
 
 -- 
 Mindaugas