panic in RELENG_5 UMA

[Andre Oppermann]

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