[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: 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.
Main Index |
Thread Index |