All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Keller, Jacob E" <jacob.e.keller@intel.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Date: Wed, 23 Nov 2022 20:16:32 +0000	[thread overview]
Message-ID: <CO1PR11MB5089116CBF3DC327E6F4C4CBD60C9@CO1PR11MB5089.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20221123141829.1825170-1-linux@rasmusvillemoes.dk>



> -----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


  reply	other threads:[~2022-11-23 20:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-23 14:18 [PATCH] net: loopback: use NET_NAME_PREDICTABLE for name_assign_type Rasmus Villemoes
2022-11-23 20:16 ` Keller, Jacob E [this message]
2022-11-25  9:50 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO1PR11MB5089116CBF3DC327E6F4C4CBD60C9@CO1PR11MB5089.namprd11.prod.outlook.com \
    --to=jacob.e.keller@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.