From: Neil Horman <nhorman@tuxdriver.com> To: Xin Long <lucien.xin@gmail.com> Cc: David Laight <David.Laight@aculab.com>, network dev <netdev@vger.kernel.org>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>, "davem@davemloft.net" <davem@davemloft.net> Subject: Re: [PATCHv2 net-next 3/5] sctp: add SCTP_EXPOSE_POTENTIALLY_FAILED_STATE sockopt Date: Mon, 14 Oct 2019 08:41:43 -0400 [thread overview] Message-ID: <20191014124143.GA11844@hmswarspite.think-freely.org> (raw) In-Reply-To: <CADvbK_fb9jjm-h-XyVci971Uu=YuwMsUjWEcv9ehUv9Q6W_VxQ@mail.gmail.com> On Mon, Oct 14, 2019 at 04:36:34PM +0800, Xin Long wrote: > On Thu, Oct 10, 2019 at 12:18 AM Neil Horman <nhorman@tuxdriver.com> wrote: > > > > On Tue, Oct 08, 2019 at 11:28:32PM +0800, Xin Long wrote: > > > On Tue, Oct 8, 2019 at 9:02 PM David Laight <David.Laight@aculab.com> wrote: > > > > > > > > From: Xin Long > > > > > Sent: 08 October 2019 12:25 > > > > > > > > > > This is a sockopt defined in section 7.3 of rfc7829: "Exposing > > > > > the Potentially Failed Path State", by which users can change > > > > > pf_expose per sock and asoc. > > > > > > > > If I read these patches correctly the default for this sockopt in 'enabled'. > > > > Doesn't this mean that old application binaries will receive notifications > > > > that they aren't expecting? > > > > > > > > I'd have thought that applications would be required to enable it. > > > If we do that, sctp_getsockopt_peer_addr_info() in patch 2/5 breaks. > > > > > I don't think we can safely do either of these things. Older > > applications still need to behave as they did prior to the introduction > > of this notification, and we shouldn't allow unexpected notifications to > > be sent. > Hi, Neil > > I think about again, and also talked with QE, we think to get unexpected > notifications shouldn't be a problem for user's applications. > On principle, I disagree. Regardless of what the RFC does, we shouldn't send notifications that an application aren't subscribed to. Just because QE doesn't think it should be a problem (and for their uses it may well not be an issue), we can't make that general assumption. > RFC actually keeps adding new notifications, and a user shouldn't expect > the specific notifications coming in some exact orders. They should just > ignore it and wait until the ones they expect. I don't think some users > would abort its application when getting an unexpected notification. > To make that assertion is to discount the purpose of the SCTP_EVENTS sockopt entirely. the SCTP_EVENTS option is a whitelist operation, so they expect to get what they subscribe to, and no more. > We should NACK patchset v3 and go with v2. What do you think? > No, we need to go with an option that maintains backwards compatibility without relying on the assumption that applications will just ignore events they didn't subscribe to. Davids example is a case in point. Neil > > > > What if you added a check in get_peer_addr_info to only return -EACCESS > > if pf_expose is 0 and the application isn't subscribed to the PF event? > > > > Neil > > > > > > > > > > David > > > > > > > > - > > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > > > > Registration No: 1397386 (Wales) > > > > > > > >
WARNING: multiple messages have this Message-ID (diff)
From: Neil Horman <nhorman@tuxdriver.com> To: Xin Long <lucien.xin@gmail.com> Cc: David Laight <David.Laight@aculab.com>, network dev <netdev@vger.kernel.org>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>, "davem@davemloft.net" <davem@davemloft.net> Subject: Re: [PATCHv2 net-next 3/5] sctp: add SCTP_EXPOSE_POTENTIALLY_FAILED_STATE sockopt Date: Mon, 14 Oct 2019 12:41:43 +0000 [thread overview] Message-ID: <20191014124143.GA11844@hmswarspite.think-freely.org> (raw) In-Reply-To: <CADvbK_fb9jjm-h-XyVci971Uu=YuwMsUjWEcv9ehUv9Q6W_VxQ@mail.gmail.com> On Mon, Oct 14, 2019 at 04:36:34PM +0800, Xin Long wrote: > On Thu, Oct 10, 2019 at 12:18 AM Neil Horman <nhorman@tuxdriver.com> wrote: > > > > On Tue, Oct 08, 2019 at 11:28:32PM +0800, Xin Long wrote: > > > On Tue, Oct 8, 2019 at 9:02 PM David Laight <David.Laight@aculab.com> wrote: > > > > > > > > From: Xin Long > > > > > Sent: 08 October 2019 12:25 > > > > > > > > > > This is a sockopt defined in section 7.3 of rfc7829: "Exposing > > > > > the Potentially Failed Path State", by which users can change > > > > > pf_expose per sock and asoc. > > > > > > > > If I read these patches correctly the default for this sockopt in 'enabled'. > > > > Doesn't this mean that old application binaries will receive notifications > > > > that they aren't expecting? > > > > > > > > I'd have thought that applications would be required to enable it. > > > If we do that, sctp_getsockopt_peer_addr_info() in patch 2/5 breaks. > > > > > I don't think we can safely do either of these things. Older > > applications still need to behave as they did prior to the introduction > > of this notification, and we shouldn't allow unexpected notifications to > > be sent. > Hi, Neil > > I think about again, and also talked with QE, we think to get unexpected > notifications shouldn't be a problem for user's applications. > On principle, I disagree. Regardless of what the RFC does, we shouldn't send notifications that an application aren't subscribed to. Just because QE doesn't think it should be a problem (and for their uses it may well not be an issue), we can't make that general assumption. > RFC actually keeps adding new notifications, and a user shouldn't expect > the specific notifications coming in some exact orders. They should just > ignore it and wait until the ones they expect. I don't think some users > would abort its application when getting an unexpected notification. > To make that assertion is to discount the purpose of the SCTP_EVENTS sockopt entirely. the SCTP_EVENTS option is a whitelist operation, so they expect to get what they subscribe to, and no more. > We should NACK patchset v3 and go with v2. What do you think? > No, we need to go with an option that maintains backwards compatibility without relying on the assumption that applications will just ignore events they didn't subscribe to. Davids example is a case in point. Neil > > > > What if you added a check in get_peer_addr_info to only return -EACCESS > > if pf_expose is 0 and the application isn't subscribed to the PF event? > > > > Neil > > > > > > > > > > David > > > > > > > > - > > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > > > > Registration No: 1397386 (Wales) > > > > > > > >
next prev parent reply other threads:[~2019-10-14 12:42 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-08 11:25 [PATCHv2 net-next 0/5] sctp: update from rfc7829 Xin Long 2019-10-08 11:25 ` Xin Long 2019-10-08 11:25 ` [PATCHv2 net-next 1/5] sctp: add SCTP_ADDR_POTENTIALLY_FAILED notification Xin Long 2019-10-08 11:25 ` Xin Long 2019-10-08 11:25 ` [PATCHv2 net-next 2/5] sctp: add pf_expose per netns and sock and asoc Xin Long 2019-10-08 11:25 ` Xin Long 2019-10-08 11:25 ` [PATCHv2 net-next 3/5] sctp: add SCTP_EXPOSE_POTENTIALLY_FAILED_STATE sockopt Xin Long 2019-10-08 11:25 ` Xin Long 2019-10-08 11:25 ` [PATCHv2 net-next 4/5] sctp: add support for Primary Path Switchover Xin Long 2019-10-08 11:25 ` Xin Long 2019-10-08 11:25 ` [PATCHv2 net-next 5/5] sctp: add SCTP_PEER_ADDR_THLDS_V2 sockopt Xin Long 2019-10-08 11:25 ` Xin Long 2019-10-08 13:02 ` [PATCHv2 net-next 3/5] sctp: add SCTP_EXPOSE_POTENTIALLY_FAILED_STATE sockopt David Laight 2019-10-08 13:02 ` David Laight 2019-10-08 15:28 ` Xin Long 2019-10-08 15:28 ` Xin Long 2019-10-09 16:15 ` Neil Horman 2019-10-09 16:15 ` Neil Horman 2019-10-10 9:28 ` Xin Long 2019-10-10 9:28 ` Xin Long 2019-10-10 12:40 ` Neil Horman 2019-10-10 12:40 ` Neil Horman 2019-10-11 15:57 ` Xin Long 2019-10-11 15:57 ` Xin Long 2019-10-11 16:25 ` Xin Long 2019-10-11 16:25 ` Xin Long 2019-10-11 21:29 ` Neil Horman 2019-10-11 21:29 ` Neil Horman 2019-10-14 8:36 ` Xin Long 2019-10-14 8:36 ` Xin Long 2019-10-14 8:49 ` David Laight 2019-10-14 8:49 ` David Laight 2019-10-14 12:41 ` Neil Horman [this message] 2019-10-14 12:41 ` Neil Horman 2019-10-14 13:48 ` David Laight 2019-10-18 15:34 ` [PATCHv2 net-next 2/5] sctp: add pf_expose per netns and sock and asoc David Laight 2019-10-18 15:34 ` David Laight 2019-10-19 8:45 ` Xin Long 2019-10-19 8:45 ` Xin Long 2019-10-22 11:29 ` David Laight 2019-10-22 11:29 ` David Laight
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=20191014124143.GA11844@hmswarspite.think-freely.org \ --to=nhorman@tuxdriver.com \ --cc=David.Laight@aculab.com \ --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 \ /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.