From: Jakub Kicinski <kuba@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Andy Ren <andy.ren@getcruise.com>,
netdev@vger.kernel.org, richardbgobert@gmail.com,
davem@davemloft.net, wsa+renesas@sang-engineering.com,
edumazet@google.com, petrm@nvidia.com, pabeni@redhat.com,
corbet@lwn.net, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, roman.gushchin@linux.dev
Subject: Re: [PATCH net-next v2] netconsole: Enable live renaming for network interfaces used by netconsole
Date: Tue, 1 Nov 2022 20:40:06 -0700 [thread overview]
Message-ID: <20221101204006.75b46660@kernel.org> (raw)
In-Reply-To: <Y2G+SYXyZAB/r3X0@lunn.ch>
On Wed, 2 Nov 2022 01:48:09 +0100 Andrew Lunn wrote:
> Changing the interface name while running is probably not an
> issue. There are a few drivers which report the name to the firmware,
> presumably for logging, and phoning home, but it should not otherwise
> affect the hardware.
Agreed. BTW I wonder if we really want to introduce a netconsole
specific uAPI for this or go ahead with something more general.
A sysctl for global "allow UP rename"?
We added the live renaming for failover a while back and there were
no reports of user space breaking as far as I know. So perhaps nobody
actually cares and we should allow renaming all interfaces while UP?
For backwards compat we can add a sysctl as mentioned or a rtnetlink
"I know what I'm doing" flag?
Maybe print an info message into the logs for a few releases to aid
debug?
IOW either there is a reason we don't allow rename while up, and
netconsole being bound to an interface is immaterial. Or there is
no reason and we should allow all.
next prev parent reply other threads:[~2022-11-02 3:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 0:24 [PATCH net-next v2] netconsole: Enable live renaming for network interfaces used by netconsole Andy Ren
2022-11-02 0:48 ` Andrew Lunn
2022-11-02 3:40 ` Jakub Kicinski [this message]
2022-11-02 17:14 ` Roman Gushchin
2022-11-02 19:54 ` Jakub Kicinski
2022-11-03 0:08 ` Roman Gushchin
2022-11-03 17:52 ` Ido Schimmel
2022-11-03 22:38 ` David Ahern
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=20221101204006.75b46660@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=andy.ren@getcruise.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=richardbgobert@gmail.com \
--cc=roman.gushchin@linux.dev \
--cc=wsa+renesas@sang-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).