From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [PATCH net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list Date: Wed, 24 Aug 2016 06:38:54 -0400 Message-ID: <20160824103854.GA13154@hmsreliant.think-freely.org> References: <130956b1e880eab780162a795fde156d61d4de0f.1471605833.git.lucien.xin@gmail.com> <20160819175007.GB3578@hmsreliant.think-freely.org> <20160822142538.GA10323@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: network dev , linux-sctp@vger.kernel.org, davem , Marcelo Ricardo Leitner , Vlad Yasevich , daniel@iogearbox.net To: Xin Long Return-path: Received: from charlotte.tuxdriver.com ([70.61.120.58]:34921 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754056AbcHXKjZ (ORCPT ); Wed, 24 Aug 2016 06:39:25 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Date: Wed, 24 Aug 2016 10:38:54 +0000 Subject: Re: [PATCH net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list Message-Id: <20160824103854.GA13154@hmsreliant.think-freely.org> List-Id: References: <130956b1e880eab780162a795fde156d61d4de0f.1471605833.git.lucien.xin@gmail.com> <20160819175007.GB3578@hmsreliant.think-freely.org> <20160822142538.GA10323@hmsreliant.think-freely.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Xin Long Cc: network dev , linux-sctp@vger.kernel.org, davem , Marcelo Ricardo Leitner , Vlad Yasevich , daniel@iogearbox.net 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