Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp477745rwb; Sun, 6 Nov 2022 08:43:31 -0800 (PST) X-Google-Smtp-Source: AMsMyM5FYAuKhTchU3E6P7qPD8ewe1+KI01+fTs4lq3rHrK889YlBKp5hdXOKKC/hD4cvA7YwLed X-Received: by 2002:a17:907:a05:b0:77b:b538:6476 with SMTP id bb5-20020a1709070a0500b0077bb5386476mr44299265ejc.324.1667753011408; Sun, 06 Nov 2022 08:43:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667753011; cv=none; d=google.com; s=arc-20160816; b=yN434oPr2onZ+W5KSXRRBJDTv7l2K5y03QPwcHth35sa0Mlj3jQw/dNpjpTn1ote2V 2a2La5rhhwpMvnpxGl2XTRlmnVg0QUpEKQY2wyBDCvynPFDlDxruSJtF4Ur5pV5Y8ZXP 2SCLbRojQQBtg/APe9r645Rp065aIB1qmJI39OA/0xkUVY4IhJEhCj+riUVpVJYg1b05 DCnb/aMuEQ+UeSBrRoG8fX5iTLUrSTeFbRGgrGW4tJwTfXQfo1Z/1LhXNtu1Ik2+BRW9 Z0yxstuDhZS9tVudp8T/0R+ZPgxM86lP1+4nCC5LqdrjRRsYkd5P0E9fSxz3UeXEv7S2 PC5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id :dkim-signature; bh=X5pQ4r+k2kEYG5/TFIF1oqBuQuZpcws5RpLX4N1nD+w=; b=aw0Yw2dfe3/jg78AYvBKbhnXJPCT1mEqOsEh3PFwX/G5XSEwnGe4ltUTlNd0EoMxiy dku2jjHiUW6hum9lOpoiqwhEDf0ShbcRrSVthL62vRzTgcwf5seOh+2DkoJB8zZvDSbt j/ihvl4HdtIe9Jnel/EZpXs0naYAXS7Vd3n/EJHLZDemOpHcBBaGfiWKQr0tAScK7p1R uOv6r8r/oC/AtoQn1hH7c2z9bNA43b2bJGUpY0JvHHXms0PJTFn+rr+bsbNHaGC4ePVM wt+jMw3DNX7JGthzCkeB/9T8zR+a61FXJqA14lJswisW0biOBMY573wS+BQu+mDFcwn1 DOkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b="OzxoD/dI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e26-20020a056402149a00b00461701dab0csi5414074edv.526.2022.11.06.08.43.06; Sun, 06 Nov 2022 08:43:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b="OzxoD/dI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229961AbiKFQY1 (ORCPT + 97 others); Sun, 6 Nov 2022 11:24:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229804AbiKFQY0 (ORCPT ); Sun, 6 Nov 2022 11:24:26 -0500 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7CB3640F; Sun, 6 Nov 2022 08:24:25 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 29539320069B; Sun, 6 Nov 2022 11:24:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 06 Nov 2022 11:24:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1667751860; x=1667838260; bh=X5pQ4r+k2kEYG5/TFIF1oqBuQuZp cws5RpLX4N1nD+w=; b=OzxoD/dI5Q3YlOu7PHmRpU9ZvqSaKdfs6IS5TUFcRtDy TzVO398h/5yu4HradbUHrD3mgO9CBDZw9U97co6VZSnvAblwq7YBoKvpgahhvs6z xDstaChr3Jb7HU3Ebtz+2hRZzZN3xvEcAnjAdVnCKcoI0Xa4vr4D3jr/WNjgZoji B+cUb1DR55Ir91aZjr6uYSurjyO3e3J2sbM+tKF4E8wYTN+Mr1e7n1qnnjahGJGu OCIQnR+eRiYLPUZQF1R+7il/c0KL0FiPKg9vR6D9TmQZ3fe9rQ9BJYT+poDgF0a4 qOIHJbpJA9/vyMVkF4UDnHTNPXCRuLFu/dbu59FxFw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvdeigdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpeehhfdtjedviefffeduuddvffegteeiieeguefgudffvdfftdefheeijedthfej keenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepihguohhstghhsehiughoshgthhdrohhrgh X-ME-Proxy: Feedback-ID: i494840e7:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 6 Nov 2022 11:24:18 -0500 (EST) Date: Sun, 6 Nov 2022 18:24:16 +0200 From: Ido Schimmel To: Andy Ren Cc: netdev@vger.kernel.org, richardbgobert@gmail.com, davem@davemloft.net, wsa+renesas@sang-engineering.com, edumazet@google.com, petrm@nvidia.com, kuba@kernel.org, pabeni@redhat.com, corbet@lwn.net, andrew@lunn.ch, dsahern@gmail.com, sthemmin@microsoft.com, sridhar.samudrala@intel.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, roman.gushchin@linux.dev Subject: Re: [PATCH net-next v2] net/core: Allow live renaming when an interface is up Message-ID: References: <20221104175434.458177-1-andy.ren@getcruise.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221104175434.458177-1-andy.ren@getcruise.com> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 04, 2022 at 10:54:34AM -0700, Andy Ren wrote: > We should allow a network interface to be renamed when the interface > is up. The motivation for this change (netconsole) is missing. I suggest: " As explained in the netconsole documentation [1], when netconsole is used as a built-in it will bring up the specified interface as soon as possible. As a result, user space will not be able to rename the interface since the kernel disallows renaming of interfaces that are administratively up unless the 'IFF_LIVE_RENAME_OK' private flag was set by the kernel. The original solution [2] to this problem was to augment the netconsole configuration parameters with a new parameter that allows renaming of the interface used by netconsole while it is administratively up. However, during the discussion that followed it became apparent that we have no reason to keep the current restriction and instead we should allow user space to rename interfaces regardless of their administrative state: 1. The restriction was put in place over 20 years ago when renaming was only possible via IOCTL and before rtnetlink started notifying user space about such changes like it does today. 2. The 'IFF_LIVE_RENAME_OK' flag was added over 3 years ago in version 5.2 and no regressions were reported. 3. In-kernel listeners to 'NETDEV_CHANGENAME' do not seem to care about the administrative state of interface. Therefore, allow user space to rename running interfaces by removing the restriction and the associated 'IFF_LIVE_RENAME_OK' flag. Help in possible triage by emitting a message to the kernel log that an interface was renamed while running. [1] https://www.kernel.org/doc/Documentation/networking/netconsole.rst [2] https://lore.kernel.org/netdev/20221102002420.2613004-1-andy.ren@getcruise.com/ " > > Live renaming was added as a failover in the past, and there has been no > arising issues of the user space breaking. Furthermore, it seems that this > flag was added because in the past, IOCTL was used for renaming, which > would not notify the user space. Nowadays, it appears that the user > space receives notifications regardless of the state of the network > device (e.g. rtnetlink_event()). The listeners for NETDEV_CHANGENAME > also do not strictly ensure that the netdev is up or not. > > Hence, we should remove the live renaming flag and checks due > to the aforementioned reasons. > > The changes are as the following: > - Remove IFF_LIVE_RENAME_OK flag declarations > - Remove check in dev_change_name that checks whether device is up and > if IFF_LIVE_RENAME_OK is set by the network device's priv_flags > - Remove references of IFF_LIVE_RENAME_OK in the failover module > > Changes from v1->v2 > - Added placeholder comment in place of removed IFF_LIVE_RENAME_OK flag > - Added extra logging hints to indicate whether a network interface was > renamed while UP I believe that nowadays the recommendation is to put the changelog under the "---" (or just use git-notes) since patches are applied with a "Link:" to lore. The code itself looks fine to me. Thanks > > Signed-off-by: Andy Ren > --- > include/linux/netdevice.h | 4 +--- > net/core/dev.c | 19 ++----------------- > net/core/failover.c | 6 +++--- > 3 files changed, 6 insertions(+), 23 deletions(-) > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index d45713a06568..4be87b89e481 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -1650,7 +1650,6 @@ struct net_device_ops { > * @IFF_FAILOVER: device is a failover master device > * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device > * @IFF_L3MDEV_RX_HANDLER: only invoke the rx handler of L3 master device > - * @IFF_LIVE_RENAME_OK: rename is allowed while device is up and running > * @IFF_TX_SKB_NO_LINEAR: device/driver is capable of xmitting frames with > * skb_headlen(skb) == 0 (data starts from frag0) > * @IFF_CHANGE_PROTO_DOWN: device supports setting carrier via IFLA_PROTO_DOWN > @@ -1686,7 +1685,7 @@ enum netdev_priv_flags { > IFF_FAILOVER = 1<<27, > IFF_FAILOVER_SLAVE = 1<<28, > IFF_L3MDEV_RX_HANDLER = 1<<29, > - IFF_LIVE_RENAME_OK = 1<<30, > + /* was IFF_LIVE_RENAME_OK */ > IFF_TX_SKB_NO_LINEAR = BIT_ULL(31), > IFF_CHANGE_PROTO_DOWN = BIT_ULL(32), > }; > @@ -1721,7 +1720,6 @@ enum netdev_priv_flags { > #define IFF_FAILOVER IFF_FAILOVER > #define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE > #define IFF_L3MDEV_RX_HANDLER IFF_L3MDEV_RX_HANDLER > -#define IFF_LIVE_RENAME_OK IFF_LIVE_RENAME_OK > #define IFF_TX_SKB_NO_LINEAR IFF_TX_SKB_NO_LINEAR > > /* Specifies the type of the struct net_device::ml_priv pointer */ > diff --git a/net/core/dev.c b/net/core/dev.c > index 3bacee3bee78..707de6b841d0 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -1163,22 +1163,6 @@ int dev_change_name(struct net_device *dev, const char *newname) > > net = dev_net(dev); > > - /* Some auto-enslaved devices e.g. failover slaves are > - * special, as userspace might rename the device after > - * the interface had been brought up and running since > - * the point kernel initiated auto-enslavement. Allow > - * live name change even when these slave devices are > - * up and running. > - * > - * Typically, users of these auto-enslaving devices > - * don't actually care about slave name change, as > - * they are supposed to operate on master interface > - * directly. > - */ > - if (dev->flags & IFF_UP && > - likely(!(dev->priv_flags & IFF_LIVE_RENAME_OK))) > - return -EBUSY; > - > down_write(&devnet_rename_sem); > > if (strncmp(newname, dev->name, IFNAMSIZ) == 0) { > @@ -1195,7 +1179,8 @@ int dev_change_name(struct net_device *dev, const char *newname) > } > > if (oldname[0] && !strchr(oldname, '%')) > - netdev_info(dev, "renamed from %s\n", oldname); > + netdev_info(dev, "renamed from %s%s\n", oldname, > + dev->flags & IFF_UP ? " (while UP)" : ""); > > old_assign_type = dev->name_assign_type; > dev->name_assign_type = NET_NAME_RENAMED; > diff --git a/net/core/failover.c b/net/core/failover.c > index 864d2d83eff4..655411c4ca51 100644 > --- a/net/core/failover.c > +++ b/net/core/failover.c > @@ -80,14 +80,14 @@ static int failover_slave_register(struct net_device *slave_dev) > goto err_upper_link; > } > > - slave_dev->priv_flags |= (IFF_FAILOVER_SLAVE | IFF_LIVE_RENAME_OK); > + slave_dev->priv_flags |= IFF_FAILOVER_SLAVE; > > if (fops && fops->slave_register && > !fops->slave_register(slave_dev, failover_dev)) > return NOTIFY_OK; > > netdev_upper_dev_unlink(slave_dev, failover_dev); > - slave_dev->priv_flags &= ~(IFF_FAILOVER_SLAVE | IFF_LIVE_RENAME_OK); > + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE; > err_upper_link: > netdev_rx_handler_unregister(slave_dev); > done: > @@ -121,7 +121,7 @@ int failover_slave_unregister(struct net_device *slave_dev) > > netdev_rx_handler_unregister(slave_dev); > netdev_upper_dev_unlink(slave_dev, failover_dev); > - slave_dev->priv_flags &= ~(IFF_FAILOVER_SLAVE | IFF_LIVE_RENAME_OK); > + slave_dev->priv_flags &= ~IFF_FAILOVER_SLAVE; > > if (fops && fops->slave_unregister && > !fops->slave_unregister(slave_dev, failover_dev)) > -- > 2.38.1 >