Subject: Re: arplookup() incrementing arpstat.as_allocfail erroneously.
To: None <itojun@iijlab.net>
From: Sean Boudreau <seanb@qnx.com>
List: tech-net
Date: 06/10/2003 11:24:15
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