On Thu, Jan 6, 2022 at 6:27 AM Andrew Lunn <andrew@xxxxxxx> wrote: > > On Wed, Jan 05, 2022 at 10:49:56PM +0100, Oliver Neukum wrote: > > > > On 05.01.22 18:30, Andrew Lunn wrote: > > > On Wed, Jan 05, 2022 at 11:14:25PM +0800, Aaron Ma wrote: > > >> When plugin multiple r8152 ethernet dongles to Lenovo Docks > > >> or USB hub, MAC passthrough address from BIOS should be > > >> checked if it had been used to avoid using on other dongles. > > >> > > >> Currently builtin r8152 on Dock still can't be identified. > > >> First detected r8152 will use the MAC passthrough address. > > > I do have to wonder why you are doing this in the kernel, and not > > > using a udev rule? This seems to be policy, and policy does not belong > > > in the kernel. > > Debatable. An ethernet NIC has to have a MAC. The kernel must > > provide one. That we should always take the one found in the > > device's ROM rather than the host's ROM is already a policy decision. > > In general, it is a much longer list of places to find the MAC address > from. It could be in three different places in device tree, it could > be in ACPI in a similar number of places, it could be in NVMEM, > pointed to by device tree, the bootloader might of already programmed > the controller with its MAC address, etc, or if everything else fails, > it could be random. > > So yes, the kernel will give it one. But if you want the interface to > have a specific MAC address, you probably should not be trusting the > kernel, given it has so many options. 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... 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. Kai-Heng > > Andrew > >
