re: CVS commit: src/sys/netinet

[Roy Marples <roy%marples.name@localhost>]

On 2015-11-06 20:07, matthew green wrote:
> Roy Marples writes:
> > 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).
>
> rarpd might need to be changed, but it shouldn't need to be "fixed"
> otherwise we've broken binary compatibility.

It was more fixing the intent of the code if the added subnet route 
allows neighbours, or if we want to continue using RTF_CLONING to mean 
that.
I'm not suggesting, or implying, we want to break binary compat.

Roy