From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 13:28:30 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44B6316A41C for ; Wed, 22 Jun 2005 13:28:30 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EEC743D53 for ; Wed, 22 Jun 2005 13:28:27 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 54007 invoked from network); 22 Jun 2005 13:19:01 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2005 13:19:01 -0000 Message-ID: <42B9677C.41ADE411@freebsd.org> Date: Wed, 22 Jun 2005 15:28:28 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: qingli@FreeBSD.org, sam@FreeBSD.org, Jeremie Le Hen , freebsd-stable@FreeBSD.org Subject: Re: panic in RELENG_5 UMA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2005 13:28:30 -0000 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