netdev - Re: [PATCH net-next 0/1] netvsc: another VF datapath fix

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 8 Aug 2017 08:15:06 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     kys@...rosoft.com, haiyangz@...rosoft.com, sthemmin@...rosoft.com,
        devel@...uxdriverproject.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/1] netvsc: another VF datapath fix

On Tue, 08 Aug 2017 16:03:56 +0200
Vitaly Kuznetsov <vkuznets@...hat.com> wrote:

> Stephen Hemminger <stephen@...workplumber.org> writes:
> 
> > Previous fix was incomplete.
> >  
> 
> Not really related to this patch series (which btw fixes my issue,
> thanks!), but I found one addition issue. Systemd fails to rename VF
> interface:
> 
>  kernel: mlx4_core 0002:00:02.0 eth2: joined to eth1
>  kernel: hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: VF registering: eth2
>  kernel: hv_netvsc 33b7a6f9-6736-451f-8fce-b382eaa50bee eth1: Data path switched to VF: eth2
>  kernel: mlx4_en: eth2: Link Up
>  NetworkManager[750]: <info>  [1502200557.0821] device (eth2): link connected
>  NetworkManager[750]: <info>  [1502200557.1004] manager: (eth2): new Ethernet device (/org/freedesktop/NetworkManager/Devices/6)
>  systemd-udevd[6942]: Error changing net interface name 'eth2' to 'enP2p0s2': Device or resource busy
>  systemd-udevd[6942]: could not rename interface '6' from 'eth2' to 'enP2p0s2': Device or resource busy
> 
> With some debug added I figured out what's wrong: __netvsc_vf_setup()
> does dev_open() which sets IFF_UP flag on the interface. When systemd
> tries to rename the interface we get into dev_change_name() and this
> fails with -EBUSY when (dev->flags & IFF_UP).
> 
> The issue is of less importance as we're not supposed to configure VF
> interface now. However, we may still want to get a stable name for it.
> 
> Any idea how this can be fixed?

The problem is Network Manager should ignore the VF device. I don't run NM on these
interfaces because it causes more issues than it helps (dueling userspace).

The driver needs to have slave track the master interface. Relying on userspace
to bring interface up leads to all the issues the bonding script had.

One option would be to delay the work of bringing up the slave device to allow
small window for renaming to run.