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: Fri, 18 Feb 2011 22:22:08 +0000

 Matthias Drochner <M.Drochner%fz-juelich.de@localhost> wrote:
 > This is still somewhat strange... The mutex is an adaptive one,
 > which cannot be taken in interrupt handlers at all. Only in
 > the softint handler. As I understand it, it is also OK for an
 > adaptive mutex to be attempted to be taken a second time,
 > even if held by the same CPU (just not by the same thread).
 > I can only suspect that the panic might be related to the
 > limited thread context of the softint handler.
 > If this is the case it would be an unnecessary limitation.
 
 Not sure what do you mean by "second time", but that sounds very wrong.
 There can be one lock owner at a time (or lock is not held) - that is a
 fundamental of mutual exclusion.  It does not behave like kernel-lock,
 which gets released/acquired around sleeps. Also,  Recursive locking is
 deliberately prohibited in our mutex(9) implementation (even in such case,
 it would be the same lock owner).
 
 Talking about limited softintr thread context - it may sleep on adaptive
 locks, but otherwise blocking is prohibited, since it is very expensive.
 
 Anyway, thanks for working on IPsec code, it really needs a major revamp.
 
 > best regards
 > Matthias
 
 -- 
 Mindaugas