On Wed, Aug 24, 2016 at 6:38 PM, Neil Horman <nhor...@tuxdriver.com> wrote: > 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.
Hi, Neil, About this patch, I think we are on the page, right ? If yes, I will repost v2, but other than improving some changelog, no other change compare to v1. Do you agree ?
