From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40F58C10F14 for ; Thu, 10 Oct 2019 12:41:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1D90220679 for ; Thu, 10 Oct 2019 12:41:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387429AbfJJMlA (ORCPT ); Thu, 10 Oct 2019 08:41:00 -0400 Received: from charlotte.tuxdriver.com ([70.61.120.58]:43686 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733191AbfJJMlA (ORCPT ); Thu, 10 Oct 2019 08:41:00 -0400 Received: from cpe-2606-a000-111b-43ee-0-0-0-115f.dyn6.twc.com ([2606:a000:111b:43ee::115f] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1iIXkP-0000xc-GX; Thu, 10 Oct 2019 08:40:55 -0400 Date: Thu, 10 Oct 2019 08:40:45 -0400 From: Neil Horman To: Xin Long Cc: David Laight , network dev , "linux-sctp@vger.kernel.org" , Marcelo Ricardo Leitner , "davem@davemloft.net" Subject: Re: [PATCHv2 net-next 3/5] sctp: add SCTP_EXPOSE_POTENTIALLY_FAILED_STATE sockopt Message-ID: <20191010124045.GA29895@hmswarspite.think-freely.org> References: <066605f2269d5d92bc3fefebf33c6943579d8764.1570533716.git.lucien.xin@gmail.com> <60a7f76bd5f743dd8d057b32a4456ebd@AcuMS.aculab.com> <20191009161508.GB25555@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Oct 10, 2019 at 05:28:34PM +0800, Xin Long wrote: > On Thu, Oct 10, 2019 at 12:18 AM Neil Horman 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 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. > > > > 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? > We can't subscribe to PF event only, but all the SCTP_PEER_ADDR_CHANGE > events. > > Now I'm thinking both PF event and "return -EACCES" in get_peer_addr_info > are new, we should give 'expose' a default value that would disable both. > How do think if we set 'pf_expose = -1' by default. We send the pf event > only if (asoc->pf_expose > 0) in sctp_assoc_control_transport(). > And if pf_expose = 0, we send the event, and return -EACCESS if we call the socket option and find a PF assoc? If so, yes, I think that makes sense. Neil > > > > Neil > > > > > > > > > > David > > > > > > > > - > > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > > > > Registration No: 1397386 (Wales) > > > > > > > >