Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/netinet



On 06/11/2015 09:24, Ryota Ozaki wrote:
> On Fri, Nov 6, 2015 at 6:09 PM, Roy Marples <roy%marples.name@localhost> wrote:
>> On 06/11/2015 08:38, Ryota Ozaki wrote:
>>> Module Name:  src
>>> Committed By: ozaki-r
>>> Date:         Fri Nov  6 08:38:43 UTC 2015
>>>
>>> Modified Files:
>>>       src/sys/netinet: if_arp.c
>>>
>>> Log Message:
>>> Fix inappropriate rt_flags check
>>>
>>> It depended on either RTF_CLONED or RTF_CLONING must be set, however,
>>> the assumption didn't meet for userland problems that create a route
>>> via RTM_ADD.
>>
>> Userland can set RTF_CLONING on any route.
>>
>>>
>>> This fixes an issue that running rarpd causes the following kernel panic
>>> reported by nonaka@:
>>>   panic: kernel diagnostic assertion "(la->la_flags & LLE_STATIC) == 0"
>>>   failed: file "/usr/src/sys/netinet/if_arp.c", line 1339
>>
>> While I agree that the panic should be fixed, should rarpd be fixed too
>> add the RTF_CLONING flag if indeed it is a subnet route on the attached
>> network or should userland never care about this flag and all added
>> routes should be considered as attached (keep in mind we want similar
>> semantics for IPv6 routes).
> 
> I prefer the latter because allowing userland programs freely setting
> flags (and other parameters) easily breaks consistency in the kernel
> (IOW that makes keeping consistency hard). Do we need some policies on
> manipulating routes from userland? Let me know if there is already.

I doubt we have any policy as such, but I would like all facets of a
route to be set from userland. During netbsd-6 development I recall
fixing the kernel so that userland could at least manipulate routes
including the automaticly added subnet route.

Certainly in our arp and ndp code the assumption is made that if a
matching route is not marked RTF_CLONING then it is not a neighbour.
When FreeBSD dropped RTF_CLONING they added the assertation that
advertised routes from rtadvd(8) are neighbours also, but this is
currently not possible to state from userland.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194485

This leads me back to my question - should all added network routes,
regardless of source match neighbour tests or do they need to be
explicitly marked as such? This has nothing todo with cloning, which is
the real purpose of the flag.

Roy


Home | Main Index | Thread Index | Old Index