iproute2/xenial: Add support for the VF Trust setting (fix IPv6 multicast under SR-IOV on Mellanox adapters)

I sent a private msg to mfo about a couple of minor nit picks I found.

Hi Eric,

Thanks for reviewing.
This is the debdiff v2, addressing the points you brought up (numbered patches, bug-ubuntu dep3 tag).

cheers,
Mauricio

Hi Eric,

This is the v3 debdiff with the patches updated to apply with no offset messages per your request.

Thanks,
Mauricio

--

Applying patch debian/patches/1008-vf_trust_dddf1b44126e.patch
patching file include/linux/if_link.h

Applying patch debian/patches/1009-vf_trust_b6d77d9ee312.patch
patching file ip/iplink.c
patching file man/man8/ip-link.8.in

Applying patch debian/patches/1010-vf_trust_fe9322781e63.patch
patching file ip/ipaddress.c

Now at patch debian/patches/1010-vf_trust_fe9322781e63.patch

Sponsored !

It is now waiting on SRU team for approval for the package to start building and be published in xenial-proposed.

Once the package found in xenial-proposed, please keep an eye here : (to make sure everything looks good)
https://people.canonical.com/~ubuntu-archive/pending-sru.html

Thanks Mauricio !

- Eric

Hello Mauricio, or anyone else affected,

Accepted iproute2 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/4.3.0-1ubuntu3.16.04.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Verification successful on xenial-proposed.
Updated verification tags.

Steps
=====

Setup 1) Enable xenial-proposed and install the iproute2 package:
---

$ echo 'deb http://archive.ubuntu.com/ubuntu xenial-proposed main restricted' | sudo tee /etc/apt/sources.list.d/xenial-proposed.list
deb http://archive.ubuntu.com/ubuntu xenial-proposed main restricted

$ sudo apt-get update

$ apt-cache madison iproute2 | grep xenial-proposed
  iproute2 | 4.3.0-1ubuntu3.16.04.4 | http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages

$ sudo apt-get install -y iproute2

$ dpkg -s iproute2 | grep Version
Version: 4.3.0-1ubuntu3.16.04.4

Setup 2) Configure 2 VFs in the ixgbe driver:
---

# lspci -s 08:00
08:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit TN Network Connection (rev 01)
08:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit TN Network Connection (rev 01)

# echo 2 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs

# dmesg | grep Virtual
[ 817.815245] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.12.1-k
[ 818.825923] ixgbevf 0000:08:10.0: Intel(R) 82599 Virtual Function
[ 818.837931] ixgbevf 0000:08:10.2: Intel(R) 82599 Virtual Function

# lspci -s 08:10
08:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
08:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)

Verification 1) Check for 'trust' in 'ip link help':
---

# ip link help 2>&1 | grep trust
                                   [ trust { on | off} ] ]

Verification 2) Check for 'trust' in 'ip link show'
---

# ip link show dev eth0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 68:05:ca:28:ff:9a brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust off

Verification 3) Set 'trust' on/off in the VFs
---

Trust setting is off by default:

# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust off

Enable trust setting on vf0:

# ip link set eth0 vf 0 trust on
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust off

Enable trust setting on vf1:

# ip link set eth0 vf 1 trust on
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust on

Disable trust setting on vf0:

# ip link set eth0 vf 0 trust off
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust on

Disable trust setting on vf1:

# ip link set eth0 vf 1 trust off
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof c...

autopkgtests for ubuntu-fan
(triggered by this iproute2 upload)

The test failure in ubuntu-fan's lxd test (the thing
that is failing in these autopkgtests) does look flaky.

Looking at autopkgtest logs for ubuntu-fan on xenial, there's a series of retriggers
for the _same_ version of docker.io that led to different results (fail/pass), in
several architectures (and on arm64 it didn't help at all yet).

Based on that, I asked Dan (ddstreet) to retrigger autopkgtests
for ubuntu-fan on xenial for iproute2 and half of architectures
now pass (summary below).

I'll ask Dan to retrigger the pending/failing architectures a
few times more.

Thus, hopefully the autopkgtest failures in the pending/failing
architectures should not be a blocker for this SRU.

Summary:
- xenial/amd64:
  - iproute2: 1x fail, then pass.
  - docker.io: 2x fail, then pass.
- xenial/arm64:
  - iproute2: 3x fail, no pass.
  - docker.io: 5x fail, no pass.
- xenial/armhf:
  - iproute2: 1x pass.
  - docker.io: 1x pass.
- xenial/i386:
  - iproute2: 2x fail, no pass.
  - docker.io: 1x fail, then pass.
- xenial/ppc64el:
  - iproute2: 1x fail, then pass.
  - docker.io: 1x pass.
- xenial/s390x:
  - iproute2: 3x fail, no pass.
  - docker.io: 1x pass.

autopkgtests for open-vm-tools,
failures in amd64 and i386.

These are consistently failing since May 14th, 2018
for a lot of other packages, thus not a change from
this upload.

Thanks,
Mauricio

This bug was fixed in the package iproute2 - 4.3.0-1ubuntu3.16.04.4

---------------
iproute2 (4.3.0-1ubuntu3.16.04.4) xenial; urgency=medium

  * Add support for VF Trust (LP: #1800877)
    - d/p/1008-vf_trust_dddf1b44126e.patch: netlink attribute
    - d/p/1009-vf_trust_b6d77d9ee312.patch: set it for kernel
    - d/p/1010-vf_trust_fe9322781e63.patch: print it for user

 -- Mauricio Faria de Oliveira <email address hidden> Tue, 18 Sep 2018 12:21:44 -0300

The verification of the Stable Release Update for iproute2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.