Subject: Re: arplookup() incrementing arpstat.as_allocfail erroneously.
To: None <itojun@iijlab.net>
From: Sean Boudreau <seanb@qnx.com>
List: tech-net
Date: 06/16/2003 09:51:28
PR 21902.

-seanb

On Tue, Jun 10, 2003 at 11:24:15AM -0400, Sean Boudreau wrote:
> On Tue, Jun 10, 2003 at 11:43:39PM +0900, itojun@iijlab.net wrote:
> > >> > 	i don't see why the diff helps the above situation.  are there any
> > >> > 	other conditions to consider?
> > >Please look again.  If an entry is found and none of the
> > >criteria that were previously were to set 'why' are satisfied,
> > >it is now returned early.  If create is not set, the entire
> > >block of calculating 'why' and incrementing arpstat.as_allocfail
> > >is now skipped and 0 is returned.
> > 
> > 	but your change doesn't make any difference to how/when
> > 	arpstat.as_allocfail gets incremented (which is your original point).
> 
> Yes it does.  The logic is different.  Before it
> went through all the error calculation before testing
> if create was set.  Then, if create wasn't set, the
> 'why' was ignored (decided it wasn't an error after all)
> but by that time arpstat.as_allocfail was already
> incremented.  The new version doesn't do any error
> calculation at all if create wasn't set.
> 
> The old version erroneously incremented arpstat.as_allocfail
> if create wasn't set, and the rtalloc1() found a route to
> the network for example ((rt->rt_flags & (RTF_GATEWAY | RTF_LLINFO)) == 0)
> 
> 
> BTW, since I have your ear.  Any verdict on the in_addprefix() / 
> in_scrubprefix() diff?
> 
> -seanb