panic: rtqkill route really not free on freebsd 8.0-release
qingli at freebsd.org
Tue Jul 6 15:35:22 UTC 2010
Thank you Xin.
Let me have a look and see if there is an alternative.
On Fri, Jul 2, 2010 at 2:26 PM, Xin LI <delphij at delphij.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> Hi, Bjoern,
> On 2010/07/02 01:39, Bjoern A. Zeeb wrote:
>> On Sat, 5 Jun 2010, Chao Shin wrote:
>>> We add kdb/ddb and extra panic info printing into kernel and catch
>>> this panic again.
>>> We have instrumented the kernel and found that this panic happens when
>>> draining == 1,
>>> but seems to be confused with the fact that all access to radix trees
>>> are protected
>>> by locks. Can anyone familiar with these code shed us some light on
>>> below is url to screenshot in ddb:
>> Did anyone pick this up?
> I don't think so.
> Currently we believe that there is some call paths that would exhibit
> the following:
> Thread A Thread B
> [ref drops to 0 now]
> (obtain rnh_lock)
> (in in_matroute)
> saw rt->ref == 0
> rt->rt_flags & RTPRF_OURS == 0
> (return from in_matroute())
> RT_LOCK(rt) <-- blocks here
> rt->rt_flags |= OURS
> RT_LOCK(rt) <-- got a wakeup
> (ref == 1 && rt->rt_flags & RTPRF_OURS)
> With the attached workaround they have not see this type of panics so
> far but that doesn't seem ideal.
> Kip and Qing's paper titled "Optimizing the BSD routing system for
> parallel processing" suggests copying the route entry rather than
> referencing it but I didn't yet on how should I implement that and do
> - --
> Xin LI <delphij at delphij.net> http://www.delphij.net/
> FreeBSD - The Power to Serve! Live free or die
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (FreeBSD)
> -----END PGP SIGNATURE-----
More information about the freebsd-net