netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: Oliver Neukum <oneukum@suse.com>,
	Aaron Ma <aaron.ma@canonical.com>,
	kuba@kernel.org, henning.schild@siemens.com,
	linux-usb@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	hayeswang@realtek.com, tiwai@suse.de
Subject: Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address
Date: Thu, 6 Jan 2022 14:27:57 +0100	[thread overview]
Message-ID: <YdbuXbtc64+Knbhm@lunn.ch> (raw)
In-Reply-To: <CAAd53p52uGFjbiuOWAA-1dN7mTqQ0KFe9PxWvPL+fjfQb9K5vQ@mail.gmail.com>

> Can udev in current form really handle the MAC race? Unless there's a
> new uevent right before ndo_open() so udev can decide which MAC to
> assign? Even with that, the race can still happen...

There will always be a race, since the kernel can start using the
interface before register_netdev() has even finished, before user
space is running. Take a look at how NFS root works.

But in general, you can change the MAC address at any time. Some MAC
drivers will return -EBUSY if the interface is up, but that is
generally artificial. After a change of MAC address ARP will time out
after a while and the link peers will get the new MAC address.

> 
> So what if we keep the existing behavior (i.e. copy MAC from ACPI),
> and let userspace daemon like NetworkManager to give the second NIC
> (r8152 in this case) a random MAC if the main NIC (I219 in this case)
> is already in use? Considering the userspace daemon has the all the
> information required and it's the policy maker here.

You should be thinking of this in more general terms. You want to
design a system that will work for any vendors laptop and dock.

You need to describe the two interfaces using some sort of bus
address, be it PCIe, USB, or a platform device address as used by
device tree etc.

Let the kernel do whatever it wants with MAC addresses for these two
interfaces. The only requirement you have is that the laptop internal
interface gets the vendor allocated MAC address, and that the dock get
some sort of MAC address, even if it is random.

On device creation, udev can check if it now has both interfaces? If
the internal interface is up, it is probably in use. Otherwise, take
its MAC address and assign it to the dock interface, and give the
internal interface a random MAC address, just in case.

You probably need to delay NetworkManager, systemd-networkkd,
/etc/network/interfaces etc, so that they don't do anything until
after udevd has settled, indicating all devices have probably been
found.

I suspect you will never get a 100% robust design, but you can
probably get it working enough for the cleaning staff and the CEO, who
have very simple setups. Power users are going to find all the corner
cases and will want to disable the udev rule.

     Andrew

  reply	other threads:[~2022-01-06 13:28 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 15:14 [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address Aaron Ma
2022-01-05 15:14 ` [PATCH 2/3] net: usb: r8152: Set probe mode to sync Aaron Ma
2022-01-05 15:33   ` Greg KH
2022-01-05 15:14 ` [PATCH 3/3] net: usb: r8152: remove unused definition Aaron Ma
2022-01-05 15:34   ` Greg KH
2022-01-05 15:31 ` [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address Greg KH
2022-01-05 15:57 ` Henning Schild
2022-01-05 17:30 ` Andrew Lunn
2022-01-05 17:40   ` Henning Schild
2022-01-05 21:49   ` Oliver Neukum
2022-01-05 22:27     ` Andrew Lunn
2022-01-06  2:10       ` Kai-Heng Feng
2022-01-06 13:27         ` Andrew Lunn [this message]
2022-01-07  2:01           ` Kai-Heng Feng
2022-01-07  2:31             ` Jakub Kicinski
2022-01-10  3:32               ` Kai-Heng Feng
2022-01-10 16:51                 ` Jakub Kicinski
2022-01-11  1:51                   ` Kai-Heng Feng
2022-01-11 14:57                     ` Limonciello, Mario
2022-01-11 16:26                       ` Jakub Kicinski
2022-01-11 16:33                         ` Limonciello, Mario
2022-01-11 16:43                           ` Jakub Kicinski
2022-01-11 16:54                             ` Limonciello, Mario
2022-01-11 17:06                               ` Jakub Kicinski
2022-01-11 17:10                                 ` Limonciello, Mario
2022-01-12 19:21                                   ` Henning Schild
2022-01-12 19:27                                     ` Limonciello, Mario
2022-01-13  3:23                                       ` Aaron Ma
2022-01-27  2:51                                         ` Aaron Ma
2022-01-27  8:06                                           ` Hayes Wang
2022-01-27  8:13                                             ` Aaron Ma
2022-01-27  8:42                                               ` Hayes Wang
2022-01-27 12:53                                             ` Andrew Lunn
2022-01-07 13:32             ` Andrew Lunn
2022-01-10  3:39               ` Kai-Heng Feng
2022-01-10 11:39 ` Oliver Neukum

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=YdbuXbtc64+Knbhm@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=aaron.ma@canonical.com \
    --cc=davem@davemloft.net \
    --cc=hayeswang@realtek.com \
    --cc=henning.schild@siemens.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=tiwai@suse.de \
    /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).