>> > 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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
