Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp594804pxb; Wed, 27 Jan 2021 16:10:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzz2GaWOmPZXM4IY+O9P1pjB2mwSQgm7hvFdAc+xEuvxF2iREBtOsxf+0SAxUM8SLUclgLb X-Received: by 2002:a17:906:e203:: with SMTP id gf3mr8737571ejb.117.1611792633551; Wed, 27 Jan 2021 16:10:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611792633; cv=none; d=google.com; s=arc-20160816; b=fKzNvWM3SAuujvGAofwfFEu3g+C90fxSDm97msyv9P4YcUPckfY3Zubq2TMaMLtkXY HK3Vx4xl3cUnWkYJrhanmFcDn+Yhkl0dTNfKk3p+e9fbIFF0WhRN2tMH76tN0lvvgTO4 h+awJDvLALJ1fCbxHSV3c6MyBJPoWVMAQez2Uouc4kqHQfK512R/jFdmLMZtFpBiph13 HUDqRy94/ghFrkFBAs/tJCcyIaAvI8xc3CdkFyImDaJUBPj2lNT5xgzFbu4lEM4lqLXn dNmBkMJVUVIxUohbcIQqWeUFfCWJxY+DhkIIMKLrPKF0cR4Lkly7KgkbYWzHvSyOJ/Je pdhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=oW5mp8XPI8J87KFQ43usYsmmtjjAtdQhi+BnJucpFYE=; b=cl/lEoU2zGjgZQBtDfNdZpYDsS0mUrq+5k1i1UCtAmt9o32XmYCYqaWvQwPeYYZYlM rOGV948/iBYBbNDWCy7NQhoHL6O/YDc8jdmHgBX0O1bBa1c8ozbanB+3aJld4s5Tv5+m 2boT0m0O5TGbrlFrtKy3yVuqCJ3S1ZhhnHxL2se0o5S4PmiDW1dtmGCzEy0OEAQ4LcJA 44g2whEqYq90QvUTtaRE0DaWykHbBoA92t0Gq+PENoys9xbb3yb46+LIhVt1Ys1cuWNO V9vTOAhFZKN/C4CNbgvWlG7Vaiu4oo6x/LnSaxt6LdAV5z5r04U2727VDO7FEA+dIl1o rVAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uUsfaWlv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i23si1774994eds.490.2021.01.27.16.10.09; Wed, 27 Jan 2021 16:10:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uUsfaWlv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344008AbhA0RhN (ORCPT + 99 others); Wed, 27 Jan 2021 12:37:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344004AbhA0Rfa (ORCPT ); Wed, 27 Jan 2021 12:35:30 -0500 Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4476CC0613D6 for ; Wed, 27 Jan 2021 09:34:48 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id d81so2693830iof.3 for ; Wed, 27 Jan 2021 09:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oW5mp8XPI8J87KFQ43usYsmmtjjAtdQhi+BnJucpFYE=; b=uUsfaWlv6TVs5zs6K/oE+oT9TTqRp8a5YCvVhkjEfazYsFU11U/46r4y4Hmodxicg5 T9WuFX9SwaWcOuJJGCSvXWwraipDzlJwp8TL84Gv5M0G+l4Y3Yt5+oy9NxXWnXN0rxXI I1NxSjpnSji1P+xBMqhi+amm7WjbuGPndYHorAWpGhAyXVRws6N0EmsG45EXJLoVRs9n EkDQBNf3/XF+R7g4kI813x0r3f/qDZAfWvTemxyOfyhcyGBlwPYWFxp0U1ZLyLy8pqTG 3MxgHvhNdiJaWVzANwE1RVWLx1uphH43/we08wn4ZC7F4vArPIw8bellaO9nEXlsyCYq 7cmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oW5mp8XPI8J87KFQ43usYsmmtjjAtdQhi+BnJucpFYE=; b=gPvgJEq1Yf0ldXurXZXewHiv8Hx+QFrCRD2X6lifqz3Xxpw+SKwldQuT/gUSTMqovJ 9MgJ7MxKH+Q2WC7zPfABiiog9kPpYDUa5Q6sax/TPtqL7KU/tXZXiriGp2ZSu/9JztIH vzTsR/VoXXrrG00qOJO36fWzKkk9kEfsXkBwR3cPbKenQxH8qxWi3815jS4ulYEd3Pkc sUMB5T2gUJyJHsUEFvQ2ZrWbm38RuJ4grOlqVOGmMHlnUZiK0gtPlVw4DI74QvVjnfR9 BpYvuq8mfALRMas7cCeEUR7M/Wv6u1TpX+i1mvvOi+nzyPzlwL/BsvL2iYKmyFz6G6BU ZdFg== X-Gm-Message-State: AOAM532j7qA2tNL7dmvTnk3quKyB1llalc3Gv0jcH5TzTS0n9g4k+z/f OSAMSvGvf3fBGucyTDrHfYTN+SlaSxprCZSSjnjyKA== X-Received: by 2002:a6b:1d1:: with SMTP id 200mr8413965iob.195.1611768887340; Wed, 27 Jan 2021 09:34:47 -0800 (PST) MIME-Version: 1.0 References: <20210127173145.58887-1-kuniyu@amazon.co.jp> In-Reply-To: <20210127173145.58887-1-kuniyu@amazon.co.jp> From: Eric Dumazet Date: Wed, 27 Jan 2021 18:34:35 +0100 Message-ID: Subject: Re: [PATCH net] net: Remove redundant calls of sk_tx_queue_clear(). To: Kuniyuki Iwashima Cc: Amit Shah , Boris Pismenny , David Miller , Jakub Kicinski , Kuniyuki Iwashima , LKML , netdev , Tariq Toukan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 27, 2021 at 6:32 PM Kuniyuki Iwashima wrote: > > From: Eric Dumazet > Date: Wed, 27 Jan 2021 18:05:24 +0100 > > On Wed, Jan 27, 2021 at 5:52 PM Kuniyuki Iwashima wrote: > > > > > > From: Eric Dumazet > > > Date: Wed, 27 Jan 2021 15:54:32 +0100 > > > > On Wed, Jan 27, 2021 at 1:50 PM Kuniyuki Iwashima wrote: > > > > > > > > > > The commit 41b14fb8724d ("net: Do not clear the sock TX queue in > > > > > sk_set_socket()") removes sk_tx_queue_clear() from sk_set_socket() and adds > > > > > it instead in sk_alloc() and sk_clone_lock() to fix an issue introduced in > > > > > the commit e022f0b4a03f ("net: Introduce sk_tx_queue_mapping"). However, > > > > > the original commit had already put sk_tx_queue_clear() in sk_prot_alloc(): > > > > > the callee of sk_alloc() and sk_clone_lock(). Thus sk_tx_queue_clear() is > > > > > called twice in each path currently. > > > > > > > > Are you sure ? > > > > > > > > I do not clearly see the sk_tx_queue_clear() call from the cloning part. > > > > > > > > Please elaborate. > > > > > > If sk is not NULL in sk_prot_alloc(), sk_tx_queue_clear() is called [1]. > > > Also the callers of sk_prot_alloc() are only sk_alloc() and sk_clone_lock(). > > > If they finally return not NULL pointer, sk_tx_queue_clear() is called in > > > each function [2][3]. > > > > > > In the cloning part, sock_copy() is called after sk_prot_alloc(), but > > > skc_tx_queue_mapping is defined between skc_dontcopy_begin and > > > skc_dontcopy_end in struct sock_common [4]. So, sock_copy() does not > > > overwrite skc_tx_queue_mapping, and thus we can initialize it in > > > sk_prot_alloc(). > > > > That is a lot of assumptions. > > > > What guarantees do we have that skc_tx_queue_mapping will never be > > moved out of this section ? > > AFAIK it was there by accident, for cache locality reasons, that might > > change in the future as we add more stuff in socket. > > > > I feel this optimization is risky for future changes, for a code path > > that is spending thousands of cycles anyway. > > If someone try to move skc_tx_queue_mapping out of the section, should > they take care about where it is used ? Certainly not. You hide some knowledge, without a comment or some runtime check. You can not ask us (maintainers) to remember thousands of tricks. > > But I agree that we should not write error-prone code. > > Currently, sk_tx_queue_clear() is the only initialization code in > sk_prot_alloc(). So, does it make sense to remove sk_tx_queue_clear() in > sk_prot_alloc() so that it does only allocation and other fields are > initialized in each caller ? > > > > > > > > [1] sk_prot_alloc > > > https://github.com/torvalds/linux/blob/master/net/core/sock.c#L1693 > > > > > > [2] sk_alloc > > > https://github.com/torvalds/linux/blob/master/net/core/sock.c#L1762 > > > > > > [3] sk_clone_lock > > > https://github.com/torvalds/linux/blob/master/net/core/sock.c#L1986 > > > > > > [4] struct sock_common > > > https://github.com/torvalds/linux/blob/master/include/net/sock.h#L218-L240 > > > > > > > > > > In any case, this seems to be a candidate for net-next, this is not > > > > fixing a bug, > > > > this would be an optimization at most, and potentially adding a bug. > > > > > > > > So if you resend this patch, you can mention the old commit in the changelog, > > > > but do not add a dubious Fixes: tag > > > > > > I see. > > > > > > I will remove the tag and resend this as a net-next candidate. > > > > > > Thank you, > > > Kuniyuki > > > > > > > > > > > > > > > > This patch removes the redundant calls of sk_tx_queue_clear() in sk_alloc() > > > > > and sk_clone_lock(). > > > > > > > > > > Fixes: 41b14fb8724d ("net: Do not clear the sock TX queue in sk_set_socket()") > > > > > CC: Tariq Toukan > > > > > CC: Boris Pismenny > > > > > Signed-off-by: Kuniyuki Iwashima > > > > > Reviewed-by: Amit Shah > > > > > --- > > > > > net/core/sock.c | 2 -- > > > > > 1 file changed, 2 deletions(-) > > > > > > > > > > diff --git a/net/core/sock.c b/net/core/sock.c > > > > > index bbcd4b97eddd..5c665ee14159 100644 > > > > > --- a/net/core/sock.c > > > > > +++ b/net/core/sock.c > > > > > @@ -1759,7 +1759,6 @@ struct sock *sk_alloc(struct net *net, int family, gfp_t priority, > > > > > cgroup_sk_alloc(&sk->sk_cgrp_data); > > > > > sock_update_classid(&sk->sk_cgrp_data); > > > > > sock_update_netprioidx(&sk->sk_cgrp_data); > > > > > - sk_tx_queue_clear(sk); > > > > > } > > > > > > > > > > return sk; > > > > > @@ -1983,7 +1982,6 @@ struct sock *sk_clone_lock(const struct sock *sk, const gfp_t priority) > > > > > */ > > > > > sk_refcnt_debug_inc(newsk); > > > > > sk_set_socket(newsk, NULL); > > > > > - sk_tx_queue_clear(newsk); > > > > > RCU_INIT_POINTER(newsk->sk_wq, NULL); > > > > > > > > > > if (newsk->sk_prot->sockets_allocated) > > > > > -- > > > > > 2.17.2 (Apple Git-113) > > > > >