Re: [PATCH] Deletion of route scrubs ifa flag IFA_ROUTE even if it's not the automatic route

[David Young <dyoung%pobox.com@localhost>]

On Tue, Mar 10, 2009 at 08:50:02PM +0000, Roy Marples wrote:
> David Young wrote:
>> On Mon, Mar 09, 2009 at 10:16:27AM +0000, Roy Marples wrote:
>>> On Tue, 2009-03-03 at 22:47 +0000, Roy Marples wrote:
>>>> To make ammends, attached is a patch to fix this. It is intended for
>>>> pullup to netbsd-5.
>>> And here is a different patch.
>>> We add a new function, rt_ifa_connected which returns 1 if the route is
>>> the connected route (prefix, subnet, etc) for the ifa.
>>> This makes the code in rtsock.c and route.c a lot simpler. I've also
>>> added some debug messages via the existing RT_DPRINTF define.
>>>
>>> For reference, I've also added a patch which applies this before my
>>> origonal patch was comitted to show the intent of what we're trying to
>>> do here.
>>>
>>> I think this pretty much covers everything now. Anyone have any issues
>>> with this before I commit?
>>
>> Please separate the cosmetic changes from the functional changes
>> before you commit.
>>
>> Avoid accessing _rt_key except by using the accessor, rt_getkey().
>>
>> Perhaps the following code logically belongs in rt_replace_ifa()?
> Yes, it makes more sense there.
>
> I will commit these patches tomorrow one after the other.
> rtsock-revert.diff reverts rtsock r1.119 restoring it to it's pristine  
> state before I touched it.
> route-ifaroute.diff has the new fix and is purely functional.
>
> I've elected to keep to the style of the current code and keeping  
> _rt_key. If it should be changed, then it should be done in another  
> patch imo, which doesn't have to be pulled up. Remember, I'm targeting  
> this for pullup to NetBSD-5.

Make sure to have a look at all of the sites that call rt_replace_ifa(),
because the callers may expect to manage IFA_ROUTE themselves.

It would be too bad if we ship a worse 5.0 kernel than possible, but if
you can workaround this defect in userland, now, instead of changing the
kernel so late in the 5.0 release cycle, with unforeseen consequences,
then we may ship a better 5.0 kernel than otherwise in the end! :-)

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933