From: "Michael S. Tsirkin" <mst@redhat.com>
To: Siwei Liu <loseweigh@gmail.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
Stephen Hemminger <stephen@networkplumber.org>,
Sridhar Samudrala <sridhar.samudrala@intel.com>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
virtualization@lists.linux-foundation.org,
virtio-dev <virtio-dev@lists.oasis-open.org>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
Alexander Duyck <alexander.h.duyck@intel.com>,
Jakub Kicinski <kubakici@wp.pl>, Jason Wang <jasowang@redhat.com>,
liran.alon@oracle.com, si-wei liu <si-wei.liu@oracle.com>
Subject: Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
Date: Thu, 21 Feb 2019 20:39:15 -0500 [thread overview]
Message-ID: <20190221203808-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CADGSJ214RJV_zWVBGv0Ydo=CJj6WESTYAH=PpaYLFHdtWVrm3g@mail.gmail.com>
On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
> Sorry for replying to this ancient thread. There was some remaining
> issue that I don't think the initial net_failover patch got addressed
> cleanly, see:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
>
> The renaming of 'eth0' to 'ens4' fails because the udev userspace was
> not specifically writtten for such kernel automatic enslavement.
> Specifically, if it is a bond or team, the slave would typically get
> renamed *before* virtual device gets created, that's what udev can
> control (without getting netdev opened early by the other part of
> kernel) and other userspace components for e.g. initramfs,
> init-scripts can coordinate well in between. The in-kernel
> auto-enslavement of net_failover breaks this userspace convention,
> which don't provides a solution if user care about consistent naming
> on the slave netdevs specifically.
>
> Previously this issue had been specifically called out when IFF_HIDDEN
> and the 1-netdev was proposed, but no one gives out a solution to this
> problem ever since. Please share your mind how to proceed and solve
> this userspace issue if netdev does not welcome a 1-netdev model.
Above says:
there's no motivation in the systemd/udevd community at
this point to refactor the rename logic and make it work well with
3-netdev.
What would the fix be? Skip slave devices?
--
MST
next prev parent reply other threads:[~2019-02-22 1:39 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 18:59 [RFC PATCH net-next v6 0/4] Enable virtio_net to act as a backup for a passthru device Sridhar Samudrala
2018-04-10 18:59 ` [RFC PATCH net-next v6 1/4] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit Sridhar Samudrala
2018-04-10 18:59 ` [RFC PATCH net-next v6 2/4] net: Introduce generic bypass module Sridhar Samudrala
2018-04-11 15:51 ` Jiri Pirko
2018-04-11 19:13 ` Samudrala, Sridhar
2018-04-18 9:25 ` Jiri Pirko
2018-04-18 18:43 ` Samudrala, Sridhar
2018-04-18 19:13 ` Jiri Pirko
2018-04-18 19:46 ` Michael S. Tsirkin
2018-04-18 20:32 ` Jiri Pirko
2018-04-18 22:46 ` Samudrala, Sridhar
2018-04-19 6:35 ` Jiri Pirko
2018-04-19 4:08 ` Michael S. Tsirkin
2018-04-19 7:22 ` Jiri Pirko
2018-04-10 18:59 ` [RFC PATCH net-next v6 3/4] virtio_net: Extend virtio to use VF datapath when available Sridhar Samudrala
2018-04-10 18:59 ` [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework Sridhar Samudrala
2018-04-10 21:26 ` Stephen Hemminger
2018-04-10 22:56 ` Samudrala, Sridhar
2018-04-10 23:28 ` Michael S. Tsirkin
2018-04-10 23:44 ` Siwei Liu
2018-04-10 23:59 ` Stephen Hemminger
2018-04-11 7:50 ` Jiri Pirko
2018-04-11 1:21 ` Michael S. Tsirkin
2018-04-11 7:53 ` Jiri Pirko
2019-02-22 1:14 ` net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework) Siwei Liu
2019-02-22 1:39 ` Michael S. Tsirkin [this message]
2019-02-22 3:33 ` [virtio-dev] " si-wei liu
[not found] ` <91d4cbb1-be7a-b53c-6b2a-99bef07e7c53@intel.com>
2019-02-22 7:55 ` si-wei liu
2019-02-22 12:58 ` Rob Miller
2019-02-22 15:14 ` Michael S. Tsirkin
2019-02-26 0:58 ` si-wei liu
2019-02-26 1:39 ` Stephen Hemminger
2019-02-26 2:05 ` Michael S. Tsirkin
2019-02-27 0:49 ` si-wei liu
2019-02-26 2:08 ` Michael S. Tsirkin
2019-02-27 0:17 ` si-wei liu
2019-02-27 21:57 ` Stephen Hemminger
2019-02-27 22:30 ` si-wei liu
2019-02-27 22:38 ` Michael S. Tsirkin
2019-02-27 23:34 ` si-wei liu
2019-02-27 23:50 ` Michael S. Tsirkin
2019-02-28 0:00 ` Liran Alon
2019-02-28 0:03 ` Stephen Hemminger
2019-02-28 0:38 ` Michael S. Tsirkin
2019-02-28 0:38 ` si-wei liu
2019-02-28 0:41 ` Michael S. Tsirkin
2019-02-28 0:52 ` Jakub Kicinski
2019-02-28 1:26 ` Michael S. Tsirkin
2019-02-28 1:52 ` Jakub Kicinski
2019-02-28 4:47 ` Michael S. Tsirkin
2019-02-28 18:13 ` Jakub Kicinski
2019-02-28 19:36 ` Michael S. Tsirkin
2019-02-28 19:56 ` Jakub Kicinski
2019-02-28 20:14 ` Michael S. Tsirkin
2019-02-28 23:31 ` Jakub Kicinski
2019-03-01 0:20 ` Siwei Liu
2019-03-01 1:05 ` Jakub Kicinski
2019-03-02 0:30 ` Siwei Liu
2019-02-28 9:32 ` si-wei liu
2019-02-28 14:26 ` Michael S. Tsirkin
2019-03-01 1:30 ` si-wei liu
2019-03-01 13:27 ` Michael S. Tsirkin
2019-03-01 20:55 ` si-wei liu
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=20190221203808-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=jasowang@redhat.com \
--cc=jesse.brandeburg@intel.com \
--cc=jiri@resnulli.us \
--cc=kubakici@wp.pl \
--cc=liran.alon@oracle.com \
--cc=loseweigh@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=si-wei.liu@oracle.com \
--cc=sridhar.samudrala@intel.com \
--cc=stephen@networkplumber.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/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).