From: David Laight <David.Laight@ACULAB.COM> To: 'Xin Long' <lucien.xin@gmail.com>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Neil Horman <nhorman@tuxdriver.com>, network dev <netdev@vger.kernel.org>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>, davem <davem@davemloft.net>, Vlad Yasevich <vyasevich@gmail.com>, "daniel@iogearbox.net" <daniel@iogearbox.net> Subject: RE: [PATCH net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list Date: Fri, 2 Sep 2016 13:22:05 +0000 [thread overview] Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB00EF186@AcuExch.aculab.com> (raw) In-Reply-To: <CADvbK_dJbaze7qMsDp-7x0xANsXZX=JfYBNhKOo=2VgbM_ywZg@mail.gmail.com> From: Of Xin Long > Sent: 25 August 2016 05:04 ... > But I still prefer the current patch. > 1. This issue only happens when server bind 'ANY' addresses. > we don't need to add any new members to struct sctp_sockaddr_entry. > especially if it's a really corner issue, we fix this as an improvement. > > 2. It's yet two issues here, the duplicate addrs may be from > a) different local NICs. > b) the same one NIC. > It may be unexpectable to filter them in NETDEV_UP/DOWN events. > > 3. We check it only when sctp really binds it, just like sctp_do_bind. > > What do you think ? I want to know what kind of weed the SCTP authors were smoking when they decided it was appropriate to put all of a systems IP addresses in the cookie and cookie-ack messages. It would be nice to have the local addresses selected by the kernel on the basis of the remote address - removing the necessity of the application to know the current network topology (and IP addresses) in order to bind to the correct local addresses before making an outward call. This sort of requires that local addresses for a connection are more of a property of the routing table than anything else. Consider the following network: ----+---------------+----------------------+--------- | | | x.x.1.1 x.x.1.2 y.y.1.2 10.1.1.1 10.1.1.2 10.1.1.2 | | | ----+---------------+ +--------- A connection from x.x.1.1 to x.x.1.2 needs to specify the 10.1.1.* addresses, but a connection for x.x.1.1 to y.y.1.2 must not. I'm not at sure whether it is possible to setup listener(s) on x.x.1.1 that can accept connections from both x.x.1.2 and y.y.1.2. David
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM> To: 'Xin Long' <lucien.xin@gmail.com>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Neil Horman <nhorman@tuxdriver.com>, network dev <netdev@vger.kernel.org>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>, davem <davem@davemloft.net>, Vlad Yasevich <vyasevich@gmail.com>, "daniel@iogearbox.net" <daniel@iogearbox.net> Subject: RE: [PATCH net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list Date: Fri, 02 Sep 2016 13:22:05 +0000 [thread overview] Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB00EF186@AcuExch.aculab.com> (raw) In-Reply-To: <CADvbK_dJbaze7qMsDp-7x0xANsXZX=JfYBNhKOo=2VgbM_ywZg@mail.gmail.com> RnJvbTogT2YgWGluIExvbmcNCj4gU2VudDogMjUgQXVndXN0IDIwMTYgMDU6MDQNCi4uLg0KPiBC dXQgSSBzdGlsbCBwcmVmZXIgdGhlIGN1cnJlbnQgcGF0Y2guDQo+IDEuIFRoaXMgaXNzdWUgb25s eSBoYXBwZW5zIHdoZW4gc2VydmVyIGJpbmQgJ0FOWScgYWRkcmVzc2VzLg0KPiAgICAgd2UgZG9u J3QgbmVlZCB0byBhZGQgYW55IG5ldyBtZW1iZXJzIHRvIHN0cnVjdCBzY3RwX3NvY2thZGRyX2Vu dHJ5Lg0KPiAgICAgZXNwZWNpYWxseSBpZiBpdCdzIGEgcmVhbGx5IGNvcm5lciBpc3N1ZSwgIHdl IGZpeCB0aGlzIGFzIGFuIGltcHJvdmVtZW50Lg0KPiANCj4gMi4gSXQncyB5ZXQgdHdvIGlzc3Vl cyAgaGVyZSwgdGhlIGR1cGxpY2F0ZSBhZGRycyBtYXkgYmUgZnJvbQ0KPiAgICBhKSBkaWZmZXJl bnQgbG9jYWwgTklDcy4NCj4gICAgYikgdGhlIHNhbWUgb25lIE5JQy4NCj4gICAgSXQgbWF5IGJl IHVuZXhwZWN0YWJsZSB0byBmaWx0ZXIgdGhlbSBpbiBORVRERVZfVVAvRE9XTiBldmVudHMuDQo+ IA0KPiAzLiBXZSBjaGVjayBpdCBvbmx5IHdoZW4gc2N0cCByZWFsbHkgYmluZHMgaXQsIGp1c3Qg bGlrZSBzY3RwX2RvX2JpbmQuDQo+IA0KPiBXaGF0IGRvIHlvdSB0aGluayA/DQoNCkkgd2FudCB0 byBrbm93IHdoYXQga2luZCBvZiB3ZWVkIHRoZSBTQ1RQIGF1dGhvcnMgd2VyZSBzbW9raW5nIHdo ZW4gdGhleQ0KZGVjaWRlZCBpdCB3YXMgYXBwcm9wcmlhdGUgdG8gcHV0IGFsbCBvZiBhIHN5c3Rl bXMgSVAgYWRkcmVzc2VzIGluIHRoZQ0KY29va2llIGFuZCBjb29raWUtYWNrIG1lc3NhZ2VzLg0K DQpJdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgdGhlIGxvY2FsIGFkZHJlc3NlcyBzZWxlY3RlZCBi eSB0aGUga2VybmVsIG9uIHRoZQ0KYmFzaXMgb2YgdGhlIHJlbW90ZSBhZGRyZXNzIC0gcmVtb3Zp bmcgdGhlIG5lY2Vzc2l0eSBvZiB0aGUgYXBwbGljYXRpb24NCnRvIGtub3cgdGhlIGN1cnJlbnQg bmV0d29yayB0b3BvbG9neSAoYW5kIElQIGFkZHJlc3NlcykgaW4gb3JkZXIgdG8gYmluZA0KdG8g dGhlIGNvcnJlY3QgbG9jYWwgYWRkcmVzc2VzIGJlZm9yZSBtYWtpbmcgYW4gb3V0d2FyZCBjYWxs Lg0KDQpUaGlzIHNvcnQgb2YgcmVxdWlyZXMgdGhhdCBsb2NhbCBhZGRyZXNzZXMgZm9yIGEgY29u bmVjdGlvbiBhcmUgbW9yZSBvZiBhDQpwcm9wZXJ0eSBvZiB0aGUgcm91dGluZyB0YWJsZSB0aGFu IGFueXRoaW5nIGVsc2UuDQoNCkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgbmV0d29yazoNCg0KICAg IC0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tDQog ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgeC54 LjEuMSAgICAgICAgIHgueC4xLjIgICAgICAgICAgICAgICAgeS55LjEuMg0KICAgIDEwLjEuMS4x ICAgICAgICAxMC4xLjEuMiAgICAgICAgICAgICAgIDEwLjEuMS4yDQogICAgICAgIHwgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAtLS0tKy0tLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLQ0KDQpBIGNvbm5lY3Rpb24gZnJvbSB4 LnguMS4xIHRvIHgueC4xLjIgbmVlZHMgdG8gc3BlY2lmeSB0aGUgMTAuMS4xLiogYWRkcmVzc2Vz LA0KYnV0IGEgY29ubmVjdGlvbiBmb3IgeC54LjEuMSB0byB5LnkuMS4yIG11c3Qgbm90Lg0KDQpJ J20gbm90IGF0IHN1cmUgd2hldGhlciBpdCBpcyBwb3NzaWJsZSB0byBzZXR1cCBsaXN0ZW5lcihz KSBvbiB4LnguMS4xDQp0aGF0IGNhbiBhY2NlcHQgY29ubmVjdGlvbnMgZnJvbSBib3RoIHgueC4x LjIgYW5kIHkueS4xLjIuDQoNCglEYXZpZA0KDQo
next prev parent reply other threads:[~2016-09-02 13:24 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-19 11:30 [PATCH net 0/2] sctp: not copying duplicate addrs to the assoc's bind address list Xin Long 2016-08-19 11:30 ` Xin Long 2016-08-19 11:30 ` [PATCH net 1/2] sctp: reduce indent level in sctp_copy_local_addr_list Xin Long 2016-08-19 11:30 ` Xin Long 2016-08-19 11:30 ` [PATCH net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list Xin Long 2016-08-19 11:30 ` Xin Long 2016-08-19 13:30 ` Neil Horman 2016-08-19 13:30 ` Neil Horman 2016-08-19 15:16 ` Xin Long 2016-08-19 15:16 ` Xin Long 2016-08-19 17:50 ` Neil Horman 2016-08-19 17:50 ` Neil Horman 2016-08-20 6:41 ` Xin Long 2016-08-20 6:41 ` Xin Long 2016-08-22 14:25 ` Neil Horman 2016-08-22 14:25 ` Neil Horman 2016-08-24 5:14 ` Xin Long 2016-08-24 5:14 ` Xin Long 2016-08-24 10:38 ` Neil Horman 2016-08-24 10:38 ` Neil Horman 2016-12-17 9:56 ` Xin Long 2016-12-17 9:56 ` Xin Long 2016-12-19 12:35 ` Neil Horman 2016-12-19 12:35 ` Neil Horman 2016-08-24 11:23 ` Marcelo Ricardo Leitner 2016-08-24 11:23 ` Marcelo Ricardo Leitner 2016-08-25 4:03 ` Xin Long 2016-08-25 4:03 ` Xin Long 2016-08-25 12:10 ` Marcelo Ricardo Leitner 2016-08-25 12:10 ` Marcelo Ricardo Leitner 2016-09-02 13:22 ` David Laight [this message] 2016-09-02 13:22 ` David Laight 2016-09-02 13:46 ` Marcelo Ricardo Leitner 2016-09-02 13:46 ` Marcelo Ricardo Leitner 2016-09-02 14:25 ` David Laight 2016-09-02 14:25 ` David Laight 2016-09-02 14:44 ` 'Marcelo Ricardo Leitner' 2016-09-02 14:44 ` 'Marcelo Ricardo Leitner'
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=063D6719AE5E284EB5DD2968C1650D6DB00EF186@AcuExch.aculab.com \ --to=david.laight@aculab.com \ --cc=daniel@iogearbox.net \ --cc=davem@davemloft.net \ --cc=linux-sctp@vger.kernel.org \ --cc=lucien.xin@gmail.com \ --cc=marcelo.leitner@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=nhorman@tuxdriver.com \ --cc=vyasevich@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.