[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: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>
Cc: kern-bug-people%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
Subject: Re: kern/44418 (FAST_IPSEC and if_wm kernel panic - may affect the
whole network stack)
Date: Fri, 11 Feb 2011 15:03:18 +0100
I've had a look at it again and with the aproach to aquire the
KENREL_LOOK in ipsec_reinject_ipstack() this way of dooing it seems to
But I've just recognised another very small whole in this patch.
(Also included in my original posting - sorry)
When the softnet_lock is aquired, the spl-level should have been already
raised to splnet/splsoftnet!
Otherwise we may hold the lock and an Interrupt on splnet/splsoftnet
could be taken.
In that interrupt we may try to lock the softnet_lock on the same CPU
again - resulting in panic ...
This whole is of cause very small, so the change to stumble over it is
very very small.
Same problem when freeing the lock again.
The order of splx()/splsoftnet() and mutex_enter()/mutex_exit() should
If that is corrected too, I think the PR can be closed.
> Synopsis: FAST_IPSEC and if_wm kernel panic - may affect the whole network
> State-Changed-From-To: open->feedback
> State-Changed-By: drochner%NetBSD.org@localhost
> State-Changed-When: Thu, 10 Feb 2011 21:28:08 +0000
> added acquisition of softnet_lock as suggested in the PR, added
> KERNEL_LOCK differently, only for ip_output.
> For me, a dual-CPU box is solid.
Dr. Nagler & Company GmbH
Tel. +49 9622/71 97-42
Fax +49 9622/71 97-50
Handelregister: Amberg HRB
USt.-ID-Nummer: DE 273143997
Geschäftsführer: Dr. Martin Nagler, Dr. Dr. Karl-Kuno Kunze
Main Index |
Thread Index |