panic in RELENG_5 UMA

[Gleb Smirnoff]

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.

- Is the following statement always true?
	la->la_rt->rt_llinfo == la

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?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE