Date: Wed, 22 Jun 2005 15:28:28 +0200 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: qingli@FreeBSD.org, sam@FreeBSD.org, Jeremie Le Hen <jeremie@le-hen.org>, freebsd-stable@FreeBSD.org Subject: Re: panic in RELENG_5 UMA Message-ID: <42B9677C.41ADE411@freebsd.org> References: <20050621070427.GA738@obiwan.tataz.chchile.org> <20050621090701.GB34406@cell.sick.ru> <20050621105154.GA36538@cell.sick.ru> <42B961B9.7A5856B3@freebsd.org> <20050622131944.GA51271@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote: > > On Wed, Jun 22, 2005 at 03:03:53PM +0200, Andre Oppermann wrote: > A> > Fixing this one is harder. We take la from unlocked rtentry obtained via > A> > rt_check(), or from arplookup(). The latter drops lock on rtentry, too. > A> > Then we do some work and use this la. It may have already been freed in > A> > arp_rtrequest(), the RTM_DELETE case. > A> > > A> > I see two approaches here: > A> > > A> > 1) Protecting llinfo with route lock. In this case we need rt_check() > A> > to return locked *rt (just reference won't help). We also need > A> > arplookup() to return locked rt. And do not unlock it withing all > A> > arpresolve() and a big part of in_arpinput() functions. > A> > A> I think for 5-stable this is the way to go. > > I have started working on this. Making arplookup() to return locked rt > looks possible. There are two more questions: > > - is it possible to make rt_check() to return locked *rt? This requires > editing nd6.c, and if_*subr.c. We can't MFC this to RELENG_5. > Probably, at first step I'll try to avoid changing rt_check and see > whether changing arplookup() is enough to avoid panics. Actually I don't know if rt_check() can return a locket *rt. > - Is the following statement always true? > la->la_rt->rt_llinfo == la Good question. I'll look into Design and Implementation of 4.4BSD and FreeBSD 5 when I get home. > A> > 2) Add mutex to llinfo_arp. I'm afraid this will hurt performance. > A> > A> The new ARP stuff should fix these issues, however it is not ready yet. > A> At the moment it looks like it wont make it right away into 6.0 but go > A> into 7-current and then MFC'd back for 6.1R. > > Yeah. I've already compiled a kernel with it. It is bootable and working, > but I haven't yet run hard tests. I'll work on locking now and perform > testing. In general it looks much better than what we have now. The locking > is going to be simple and straightforward. Thanks for nice code! Do you > mind if I pull it into a perforce branch to work on it together? Better wait a bit before you pull it into perforce. First we have to move Qing along and second I'd like to do one more iteration with him over the code. There are a couple of rough edges and style issues I'd like to carve out first. And then there is the tab-space problem which makes it a pain importing. We need to fix Qing's editor as the very first thing. ;-) -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42B9677C.41ADE411>