netdev - Re: No networking due to "net/mlx5e: Add support for devlink-port in non-representors mode"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <90C3FFD4-C7E9-4B93-99E1-F1980EAA246D@lca.pw>
Date:   Wed, 25 Mar 2020 23:18:12 -0400
From:   Qian Cai <cai@....pw>
To:     Saeed Mahameed <saeedm@...lanox.com>
Cc:     Moshe Shemesh <moshe@...lanox.com>, Jiri Pirko <jiri@...lanox.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Parav Pandit <parav@...lanox.com>,
        Vladyslav Tarasiuk <vladyslavt@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: No networking due to "net/mlx5e: Add support for devlink-port in
 non-representors mode"



> On Mar 25, 2020, at 8:17 PM, Saeed Mahameed <saeedm@...lanox.com> wrote:
> 
> On Wed, 2020-03-25 at 16:25 -0400, Qian Cai wrote:
>>> On Mar 25, 2020, at 3:33 PM, Moshe Shemesh <moshe@...lanox.com>
>>> wrote:
>>> 
>>> 
>>> On 3/25/2020 6:01 AM, Qian Cai wrote:
>>>> Reverted the linux-next commit c6acd629ee (“net/mlx5e: Add
>>>> support for devlink-port in non-representors mode”)
>>>> and its dependencies,
>>>> 
>>>> 162add8cbae4 (“net/mlx5e: Use devlink virtual flavour for VF
>>>> devlink port”)
>>>> 31e87b39ba9d (“net/mlx5e: Fix devlink port register sequence”)
>>>> 
>>>> on the top of next-20200324 allowed NICs to obtain an IPv4
>>>> address from DHCP again.
>>> 
>>> These patches should not interfere DHCP.
>>> 
>>> You might have dependencies on interface name which was changed by
>>> this patch, please check.
>> 
>> Yes,
>> 
>> Before,
>> [  238.225149][ T2021] mlx5_core 0000:0b:00.1 enp11s0f1: renamed from
>> eth1
>> [  238.511324][ T2035] mlx5_core 0000:0b:00.0 enp11s0f0: renamed from
>> eth0
>> 
>> Now,
>> [  234.448420][ T2013] mlx5_core 0000:0b:00.1 enp11s0f1np1: renamed
>> from eth1
>> [  234.664236][ T2042] mlx5_core 0000:0b:00.0 enp11s0f0np0: renamed
>> from eth0
>> 
> 
> it is not a good idea to use the interface name as a unique identifier,
> this is not resilient for kernel updates or configuration updates, e.g
> installing an extra card
> 
> Just use the HW mac address as a unique identifier in the network 
> scripts:
> 
> from [1]:
> HWADDR=MAC-address
> where MAC-address is the hardware address of the Ethernet device in the
> form AA:BB:CC:DD:EE:FF. This directive must be used in machines
> containing more than one NIC to ensure that the interfaces are assigned
> the correct device names regardless of the configured load order for
> each NIC's module. 
> 
> [1] 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-networkscripts-interfaces

Is it really necessary to cause a device naming change?

The installer/NetworkManager here (annaconda) will create those files automatically.
They don’t usually use hard-coded HWADDR. Ironically, it is RHEL-8.1.

# cat /etc/sysconfig/network-scripts/ifcfg-enp11s0f0
# Generated by dracut initrd
NAME="enp11s0f0"
DEVICE="enp11s0f0"
ONBOOT=yes
NETBOOT=yes
UUID="be2237f3-e40b-4404-be6c-bcb484dbebf6"
IPV6INIT=yes
BOOTPROTO=dhcp
TYPE=Ethernet

# cat /etc/sysconfig/network-scripts/ifcfg-enp11s0f1
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp11s0f1
UUID=400773fc-5436-4a85-9cee-a8e18cee9230
DEVICE=enp11s0f1
ONBOOT=no

Imagining a kernel update from enterprise distros contain those patches which
would break all those existing setup. It is trivial for me to fix myself, but it could
be a different story for those customers with thousand of machines need to
change.