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=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 9FACAC43381 for ; Thu, 14 Mar 2019 12:04:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5EB122085A for ; Thu, 14 Mar 2019 12:04:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XY8nw8Qx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726837AbfCNMEi (ORCPT ); Thu, 14 Mar 2019 08:04:38 -0400 Received: from mail-qt1-f195.google.com ([209.85.160.195]:33967 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726501AbfCNMEh (ORCPT ); Thu, 14 Mar 2019 08:04:37 -0400 Received: by mail-qt1-f195.google.com with SMTP id k2so5694974qtm.1 for ; Thu, 14 Mar 2019 05:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3cljYKVEwQOA6EagCI9L0WpfXelQEhpZZ/o+fhN/atk=; b=XY8nw8QxQtscMkVlbXngaoWxRJRzkMFrTtAvLHQ1rrkty4MEEqPjJFfhHxMmWk4LFB R2K/9m8wJ0GlsXSLjDwWHXWjkOtPiiw6Qp+Aj7hdbrzNoVyR6rBuUnEFIsJAnquRKlsc Gzowue4CbgiQYZ2HVt+DI0irnwIqpcw8dZ2Wh+ZjbtLqmW4tvV0vaW2XOQU27NxS0M3w iIfDnDPgOQreUURjDl280bIOjYxUq8gWkoYiOGu/zQZNwN65+VMjOuuFDuYAz5BwkZWS pI5L2zeA7e36G7soTby5oSs69j3jD+YmykGYJvbCHKC50RU9/x1ChicGBh3NlGF04uvP GGCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3cljYKVEwQOA6EagCI9L0WpfXelQEhpZZ/o+fhN/atk=; b=tDGqhvcyyPXq/J7bFRO5OxAqfVB2WqLYQhmWqFv/NCSxarrHs93vnHtcoq+6LR9siZ fTXS61h8fklwucZJSaHMtncV5zBXdlZSC+NKvE0XdDR/7q5WIPMjvmKBlmfjqbteqF0Y +afe8z3dfGvKD+JwvtPCb887uOsNaCL5BQp2qrbM9XZgWhZg17p0SLv2l9gsUP0u6DN0 2cRhkG5BhfeOeCU8Qw4ZSB6+VlY0lKn8DXqWf+CNf00bTmpLYaDwNFsCsBfiKf7sYopZ lBFZE1JYq9lxSM/F92zQrZzKyFqQl2T8ps6u2eVx/Hme1aqbMGeHfq0g87PhwMUCgShg V65g== X-Gm-Message-State: APjAAAV5Ieb8xL2M3WqK7jay8nURi3ijgJ4B8kHXyX88QvdsrKbnGYOZ a7Y2pbJ0pUF3Gf9i5fp4PSTPJLrk X-Google-Smtp-Source: APXvYqzbtpykruFadQyQDYApe6Q/dR0i49yN34E6VIz8FeafHJIhy7+8ayjGGRFWhd14WjyDIpuF0g== X-Received: by 2002:a0c:f890:: with SMTP id u16mr5825691qvn.154.1552565075892; Thu, 14 Mar 2019 05:04:35 -0700 (PDT) Received: from localhost.localdomain ([168.181.49.22]) by smtp.gmail.com with ESMTPSA id w8sm13200953qkw.80.2019.03.14.05.04.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Mar 2019 05:04:35 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 1000) id 7502F180C4F; Thu, 14 Mar 2019 09:04:32 -0300 (-03) Date: Thu, 14 Mar 2019 09:04:32 -0300 From: Marcelo Ricardo Leitner To: Xin Long Cc: David Miller , network dev , Neil Horman Subject: Re: [PATCH RFC v4 0/5] SCTP: Event skb list overhaul. Message-ID: <20190314120432.GJ13343@localhost.localdomain> References: <20190311.200919.2201899718784012074.davem@davemloft.net> <20190313160621.GI13343@localhost.localdomain> <20190314012344.GA13514@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Mar 14, 2019 at 03:51:59PM +0800, Xin Long wrote: > On Thu, Mar 14, 2019 at 9:23 AM Marcelo Ricardo Leitner > wrote: > > > > On Wed, Mar 13, 2019 at 01:06:21PM -0300, Marcelo Ricardo Leitner wrote: > > > On Mon, Mar 11, 2019 at 08:09:19PM -0700, David Miller wrote: > > > > > > > > This patch series eliminates the explicit reference to the skb list > > > > implementation via skb->prev dereferences. > > > > > > > > The approach used is to pass a non-empty skb list around instead of an > > > > event skb object which may or may not be on a list. > > > > > > > > I'd like to thank Marcelo Leitner, Xin Long, and Neil Horman for > > > > reviewing previous versions of this series. > > > > > > > > Testing would be very much appreciated, in addition to the review of > > > > course. > > > > > > > > v3 --> v4: Fix the logic in patch #4 so that we don't miss cases > > > > where we should add event to the on-stack temp list. > > > > > > > > Signed-off-by: David S. Miller > > > > > > Code review LGTM too. > > > Running some tests, should be done by the end of the day. > > > > Tests were good with the exception of one unrelated issue. ACK from my > > side thus. > > > > > > Xin, would you mind carrying forward this fix? I think we need to fix > > the other sockopts too. Thanks! > Sure, it seems to affect quite a few socket opts. Thanks. > Somehow I made sense of it before. For me too :-) > So with this patch, asoc_id will be completed ignored by TCP type socket? Yes. It already is when looking for the asoc, by sctp_id2assoc(). Just need to re-ignore it if there is no asoc yet. > > > > > ---8<--- > > > > From ddba48476b343dce84a82036e7914a1f7ac3f0c8 Mon Sep 17 00:00:00 2001 > > Message-Id: > > From: Marcelo Ricardo Leitner > > Date: Wed, 13 Mar 2019 22:13:52 -0300 > > Subject: [PATCH] net/sctp: fix ignoring asoc_id for tcp-style sockets on > > setsockopt > > > > Currently if the user pass an invalid asoc_id to SCTP_DEFAULT_SEND_PARAM > > on a TCP-style socket, it will silently ignore the new parameters. > > That's because after not finding an asoc, it is checking asoc_id against > > the known values of CURRENT/FUTURE/ALL values and that fails to match. > > > > IOW, if the user supplies an invalid asoc id or not, it should either > > match the current asoc or the socket itself so that it will inherit > > these later. Fixes it by forcing asoc_id to SCTP_FUTURE_ASSOC in case it > > is a TCP-style socket without an asoc, so that the values get set on the > > socket. > > > > Fixes: 707e45b3dc5a ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DEFAULT_SEND_PARAM sockopt") > > Signed-off-by: Marcelo Ricardo Leitner > > --- > > net/sctp/socket.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c > > index 533207dbeae955604a6304a8f67b65c9f580fd05..85205a2d9a7dc5c289a94bf4672b240040cbb546 100644 > > --- a/net/sctp/socket.c > > +++ b/net/sctp/socket.c > > @@ -3024,6 +3024,9 @@ static int sctp_setsockopt_default_send_param(struct sock *sk, > > return 0; > > } > > > > + if (sctp_style(sk, TCP)) > > + info.sinfo_assoc_id = SCTP_FUTURE_ASSOC; > > + > > if (info.sinfo_assoc_id == SCTP_FUTURE_ASSOC || > > info.sinfo_assoc_id == SCTP_ALL_ASSOC) { > > sp->default_stream = info.sinfo_stream; > > -- > > 2.20.1 > >