On Wed, Aug 24, 2016 at 01:14:27PM +0800, Xin Long wrote:
> >> > Ah, I see what you're doing. Ok, this makes some sense, at least on the
> >> > receive
> >> > side, when you get a cookie unpacked and modify the remote peers address
> >> > list,
> >> > it makes sense to check for duplicates. On the local side however, I
> >> > would,
> >> > instead of checking it when the list gets copied, I'd check it when the
> >> > master
> >> > list gets updated (in the NETDEV_UP event notifier for the local address
> >> > list,
> >>
> >> I was thinking about to check it in the NETDEV_UP, yes it can make the
> >> master list has no duplicated addresses. But what if two same addresses
> >> events come, and they come from different NICs (though I can't point out
> >> the valid use case), then we filter there.
> >>
> > That I think would be a bug in the protocol code. For the ipv4 case, all
> > addresses are owned by the system and the same addresses added to multiple
> > interfaces should not be allowed. The same is true of ipv6 case. The only
> > exception there is a link local address and that should still be unique
> > within
> > the context of an address/dev tuple.
> >
> understand, just sounds a little harsh. :-)
>
> For now, does it make sense to you to just leave as the master list
> is, and check
> the duplicate address when sctp is really binding them ?
>
I would think so, yes.
Neil
