Message ID | 20221123141829.1825170-1-linux@rasmusvillemoes.dk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:b599:b0:88:f841:fdc9 with SMTP id df25csp2166819dyb; Wed, 23 Nov 2022 06:23:33 -0800 (PST) X-Google-Smtp-Source: AA0mqf5roP1EBHV9+51yfT+DJo8qBDPtRwICZ4H3X+RlBSjxW+b1F9oVdFdXChYiMNEA8P6ATct+ X-Received: by 2002:a17:90a:d24e:b0:218:b478:f44f with SMTP id o14-20020a17090ad24e00b00218b478f44fmr9028262pjw.232.1669213413716; Wed, 23 Nov 2022 06:23:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669213413; cv=none; d=google.com; s=arc-20160816; b=d302rW8y/Jp04ghrjFXicJdPxRKtFWDLa+5t4O7pzdI0mmUPNSRXpBAdBTUMJQTJ47 h79AUdFPjJP+797hKIbnGinSuV4raHK7/r0Fhtfr61crufWCgWvrLV/Gx5Yz702DtRH6 yUaX0wqfabArjT3oQq0mCvB/6MvXWbyH4Iq91hxXxv5zOaM3Ze8r6YpZ8Mc0LqLhpJrt E7JsLOacww2vsz8JxcspcEawNRme46fOCZZ1RH2V3yy12wXvk37q+p7s0Uk5bjiJ+ENM qopoeJ2q7DMMHCSWQiZ18NU0+ywO95ietRHC/Xa62e/JgmyRaN4Syt3iBDdYi85ouxYr Zufw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Cl/DMCkVzUgLuaiNEp4gc18HhldIP35Tm09AOeDeV9U=; b=b1jcY84RVIZZEeFpK3Acp5vuVYl2lTBJfYdxLCb1LkXriI1CUjBynjy/dRvM4w99dM JOtaLW4rzdiK1/FRn3Hp7UdcQQwHct5T3BMU5nFhDvF+XCuZpRNaOv9JglxMpPIC+mFC lBb0+SsEe7tAZ3zR/LEGO/g99gnc36vPrdpsceWcSPGvBS5o3dsV5FVQ7DraNRpg/0QO m5SI2H2RT5yRs9gegNKxGfK+/WTPIPZKjHYHdhQwjG21QNVm4/ufOvmKwf24KJENFJe5 rJ3rGHIC5OOCl/NEY/WqpULtqVebnlKaek60LGuKH5ZpfjM00LylEPVHbjUvQ7kFGxKI 58AQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=GgITb1xt; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ay6-20020a056a00300600b0056bc1d790ebsi16559566pfb.57.2022.11.23.06.23.19; Wed, 23 Nov 2022 06:23:33 -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=@rasmusvillemoes.dk header.s=google header.b=GgITb1xt; 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 S235959AbiKWOSi (ORCPT <rfc822;fengqi706@gmail.com> + 99 others); Wed, 23 Nov 2022 09:18:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236375AbiKWOSf (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 23 Nov 2022 09:18:35 -0500 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A142C60685 for <linux-kernel@vger.kernel.org>; Wed, 23 Nov 2022 06:18:33 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id p8so28321030lfu.11 for <linux-kernel@vger.kernel.org>; Wed, 23 Nov 2022 06:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=Cl/DMCkVzUgLuaiNEp4gc18HhldIP35Tm09AOeDeV9U=; b=GgITb1xtbaR4nlUqLZl+/t04P5pi5eDHXqxJ72OCRCj7Ykd9AiqDBcgbeJ2PEvsfUn upWMb02KZ+BbzXJOwUyZ1xgpvC8UJIiZHhB46LMq6OMpEabgn4qYIc1ZjcMhnAcNYwr+ /x0fQC6UDGQQRmr3RHxN4tvq+FGwZ7agPRRKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Cl/DMCkVzUgLuaiNEp4gc18HhldIP35Tm09AOeDeV9U=; b=1dOzDUcp/nu85a6CVCxwBiuNYAkWvPuMwf8d18cI25dQedMWKCYwvk46RgxQsAhpHk hFQq18OLBUMxQibzTlffj/6mPbjSdURPdes9qlSEEGQO9rrf/65GK8jjPBg3vykrl6yg XwhAR5ws6TNmFpKMlxAx+U4U/TuolawiewD2p1x82H2sJTJKuumumyLr2Ys863+qxfCf sMWEsiRsqhrib70mTfnCa6rKHCOPA2SmcgBsV1pOl1Ma6jd7Be9J0a37RK+XYVgh3OPx TFH1apw8yBXtnNECkWDiqF784mz1hC7mi4ke7rHnRqqPAezpZBL7qwdskpFKI8gbP3fT gqiQ== X-Gm-Message-State: ANoB5pnSh/4W+cMQBZ2tSP0t8OcKEWC/YloboNTW3UTsWyr7IITiZndk ky2NwnIOXtHiq0BMwkJcRkebog== X-Received: by 2002:a05:6512:3b88:b0:4a3:9533:f4c9 with SMTP id g8-20020a0565123b8800b004a39533f4c9mr3669283lfv.615.1669213111973; Wed, 23 Nov 2022 06:18:31 -0800 (PST) Received: from prevas-ravi.prevas.se ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id k14-20020ac2456e000000b004a478c2f4desm2898619lfm.163.2022.11.23.06.18.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 06:18:31 -0800 (PST) From: Rasmus Villemoes <linux@rasmusvillemoes.dk> To: "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] net: loopback: use NET_NAME_PREDICTABLE for name_assign_type Date: Wed, 23 Nov 2022 15:18:28 +0100 Message-Id: <20221123141829.1825170-1-linux@rasmusvillemoes.dk> X-Mailer: git-send-email 2.37.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750297124604927905?= X-GMAIL-MSGID: =?utf-8?q?1750297124604927905?= |
Series |
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
|
|
Commit Message
Rasmus Villemoes
Nov. 23, 2022, 2:18 p.m. UTC
When the name_assign_type attribute was introduced (commit
685343fc3ba6, "net: add name_assign_type netdev attribute"), the
loopback device was explicitly mentioned as one which would make use
of NET_NAME_PREDICTABLE:
The name_assign_type attribute gives hints where the interface name of a
given net-device comes from. These values are currently defined:
...
NET_NAME_PREDICTABLE:
The ifname has been assigned by the kernel in a predictable way
that is guaranteed to avoid reuse and always be the same for a
given device. Examples include statically created devices like
the loopback device [...]
Switch to that so that reading /sys/class/net/lo/name_assign_type
produces something sensible instead of returning -EINVAL.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
This is mostly cosmetic, but ideally I'd like to get to a situation
where I don't need to do
assign_type=$(cat /sys/class/net/$dev/name_assign_type 2> /dev/null || echo 0)
or otherwise special-case [ $dev = "lo" ].
As always, there's a small chance that this could cause a regression,
but it seems extremely unlikely that anybody relies on
/sys/class/net/lo/name_assign_type being unreadable and thus
effectively is known to be NET_NAME_UNKNOWN.
drivers/net/loopback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
> -----Original Message----- > From: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Sent: Wednesday, November 23, 2022 6:18 AM > To: David S. Miller <davem@davemloft.net>; Eric Dumazet > <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni > <pabeni@redhat.com> > Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>; netdev@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: [PATCH] net: loopback: use NET_NAME_PREDICTABLE for > name_assign_type > > When the name_assign_type attribute was introduced (commit > 685343fc3ba6, "net: add name_assign_type netdev attribute"), the > loopback device was explicitly mentioned as one which would make use > of NET_NAME_PREDICTABLE: > > The name_assign_type attribute gives hints where the interface name of a > given net-device comes from. These values are currently defined: > ... > NET_NAME_PREDICTABLE: > The ifname has been assigned by the kernel in a predictable way > that is guaranteed to avoid reuse and always be the same for a > given device. Examples include statically created devices like > the loopback device [...] > Heh, so the doc says loopback is an example of this but we weren't using it for that :D > Switch to that so that reading /sys/class/net/lo/name_assign_type > produces something sensible instead of returning -EINVAL. > This seems reasonable to me. > Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > --- > > This is mostly cosmetic, but ideally I'd like to get to a situation > where I don't need to do > > assign_type=$(cat /sys/class/net/$dev/name_assign_type 2> /dev/null || echo > 0) > > or otherwise special-case [ $dev = "lo" ]. > > As always, there's a small chance that this could cause a regression, > but it seems extremely unlikely that anybody relies on > /sys/class/net/lo/name_assign_type being unreadable and thus > effectively is known to be NET_NAME_UNKNOWN. > I don't think I would consider this a regression. Previously name_assign_type was returning an error here, now it reports something useful. And we know the name is predictable because it is the loopback device. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> > drivers/net/loopback.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c > index 14e8d04cb434..2e9742952c4e 100644 > --- a/drivers/net/loopback.c > +++ b/drivers/net/loopback.c > @@ -211,7 +211,7 @@ static __net_init int loopback_net_init(struct net *net) > int err; > > err = -ENOMEM; > - dev = alloc_netdev(0, "lo", NET_NAME_UNKNOWN, loopback_setup); > + dev = alloc_netdev(0, "lo", NET_NAME_PREDICTABLE, loopback_setup); > if (!dev) > goto out; > > -- > 2.37.2
Hello: This patch was applied to netdev/net.git (master) by David S. Miller <davem@davemloft.net>: On Wed, 23 Nov 2022 15:18:28 +0100 you wrote: > When the name_assign_type attribute was introduced (commit > 685343fc3ba6, "net: add name_assign_type netdev attribute"), the > loopback device was explicitly mentioned as one which would make use > of NET_NAME_PREDICTABLE: > > The name_assign_type attribute gives hints where the interface name of a > given net-device comes from. These values are currently defined: > ... > NET_NAME_PREDICTABLE: > The ifname has been assigned by the kernel in a predictable way > that is guaranteed to avoid reuse and always be the same for a > given device. Examples include statically created devices like > the loopback device [...] > > [...] Here is the summary with links: - net: loopback: use NET_NAME_PREDICTABLE for name_assign_type https://git.kernel.org/netdev/net/c/31d929de5a11 You are awesome, thank you!
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c index 14e8d04cb434..2e9742952c4e 100644 --- a/drivers/net/loopback.c +++ b/drivers/net/loopback.c @@ -211,7 +211,7 @@ static __net_init int loopback_net_init(struct net *net) int err; err = -ENOMEM; - dev = alloc_netdev(0, "lo", NET_NAME_UNKNOWN, loopback_setup); + dev = alloc_netdev(0, "lo", NET_NAME_PREDICTABLE, loopback_setup); if (!dev) goto out;