[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/44418 (FAST_IPSEC and if_wm kernel panic - may affect the whole network stack)
The following reply was made to PR kern/44418; it has been noted by GNATS.
From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>
Cc: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@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
Main Index |
Thread Index |