Date: Tue, 6 Jul 2010 08:35:13 -0700 From: Qing Li <qingli@freebsd.org> To: d@delphij.net Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Sam Leffler <sam@freebsd.org>, Chao Shin <quakelee@geekcn.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: panic: rtqkill route really not free on freebsd 8.0-release update Message-ID: <AANLkTin40fU8AJIaVIm8rW3j3qWtdta8sLU3zEsaBtae@mail.gmail.com> In-Reply-To: <4C2E598D.2000201@delphij.net> References: <op.vdth7zm7hnq548@quakelee-work> <20100702083902.D14969@maildrop.int.zabbadoz.net> <4C2E598D.2000201@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you Xin. Let me have a look and see if there is an alternative. -- Qing On Fri, Jul 2, 2010 at 2:26 PM, Xin LI <delphij@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: >> >> Hey, >> >>> 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 =3D=3D 1, >>> but seems to be confused with the fact that all access to radix trees >>> are protected >>> by locks. =A0Can anyone familiar with these code shed us some light on >>> this? >>> >>> below is url to screenshot in ddb: >>> http://www.delphij.net/zhao/1.png >>> http://www.delphij.net/zhao/2.png >> >> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thread B > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(...) > RTLOCK(rt) > rt->ref--; > [ref drops to 0 now] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(obtain rnh_lock) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(in in_matroute) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0saw rt->ref =3D=3D 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rt->rt_flags & RTPRF_OURS = =3D=3D 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(return from in_matroute()= ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RT_LOCK(rt) <-- blocks her= e > rt->rt_flags |=3D OURS > RT_UNLOCK(rt); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RT_LOCK(rt) <-- got a wake= up > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rt->ref++ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ref =3D=3D 1 && rt->rt_fl= ags & 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 > benchmark... > > Cheers, > - -- > Xin LI <delphij@delphij.net> =A0 =A0http://www.delphij.net/ > FreeBSD - The Power to Serve! =A0 =A0 =A0 =A0 =A0Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.15 (FreeBSD) > > iQEcBAEBCAAGBQJMLlmNAAoJEATO+BI/yjfBzvAIANjmEXX54lryJ6Qq37yUFdmd > BQqw7r/Q7IYD6gOBU0/iMUySa4x6H3U+8TPUK8Rf+ARkG8CP3JsRMPJtLkFs5Eby > lmvQDRcfcKzFCAC40m/FmdlCl0c2Q/mz5H4PYve3zuU+BEDN0NOEIUtnYVmOJK1U > 4O5XXZcAzNT1BXKKwbogwQq0t4dhT/3+4inH6vC3w8HpzwDfXS2GogFSOYlSurvC > h7b2wjrD7sgTPZZj1DN7qWjGSRNAao+AGzlzvQR6tNCqWV+bn8qF+QaNoFepev+g > ITeUh9IXffn646WCRF5whKUjz+M9IvSPhqGiFyWfhcGj8DbDt074XMsHiBLh7nc=3D > =3DlHSK > -----END PGP SIGNATURE----- >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin40fU8AJIaVIm8rW3j3qWtdta8sLU3zEsaBtae>