Re: CVS commit: src/sys/netinet

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Fri, Nov 6, 2015 at 7:01 PM, Roy Marples <roy%marples.name@localhost> wrote:
> 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.

Just confirmation, do you mean s/not a neighbour/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

Hmm, I don't notice this case. Does it indicate that it is possible
that a route has both RTF_LLINFO and RTF_CLONING? Or just we can
think a route with RTF_CLONING as a neighbor?

Could you clarify what does dhcpcd actually require on routes (and
routing flags)?

>
> 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.

Well, I don't have an answer yet. I think I don't know enough
about userland requirements. How do you think of that?

  ozaki-r