[Bug 1720126] Re: [ip link] Message truncated error for large number of passthrough VFs

[Nish Aravamudan]

@mvandenberg,

Couple of nits in your debdiffs.

1) changelogs are targetting UNRELEASED, please update to xenial and
trusty respectively.

2) Is there a reason your fix is different than the fix upstream/Debian?
Does Debian need your version instead?

3) Please use appropriate DEP3 headers (dpkg-source --commit creates a
template patch with them): http://dep.debian.net/deps/dep3/, especially
Origin (not Origin/Author).

4) The actual author appears to be Phil Sutter, not Jan Gutter, although
Jan authored the patch in this bug. Consider using dep3changelog once
you have a quilt patch to generate the changelog in the standard format
(with an attribution to Phil or Jan as you decide).

5) The trusty version number seems off, it should be 3.12.0-2ubuntu1.1.
Please take a look at
https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging.

Can you fix these up and reupload the debdiffs?

Thanks,
Nish

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1720126

Title:
  [ip link] Message truncated error for large number of passthrough VFs

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Trusty:
  New
Status in iproute2 source package in Xenial:
  Confirmed
Status in iproute2 source package in Zesty:
  Fix Released
Status in iproute2 package in CentOS:
  Unknown

Bug description:
  [Impact]

  When querying a Physical Function netdev with a large amount of VF's
  (more than 30), the resulting return message can overflow the 16K
  netlink message buffer.

  This can be fixed by enabling message peeking on the socket and
  resizing the buffer on receive, or by simply enlarging the receive
  buffer.

  Since there's an upper limit to the number of VF's per PF, it's
  relatively sane to just enlarge the receive buffer. Please see the
  attached patch.

  [Test Case]

  # Set up 60 VF's on an SR-IOV device
  ip link show > /dev/null

  Observe the following:
  Message truncated
  Message truncated
  Message truncated

  [Regression Potential]

  1) Applications relying on the broken behaviour will need to be updated, but it would be a really dubious use case.
  2) Increasing the rx buffer size increases the memory footprint (but realistically, this is tiny).
  3) Extra processing time is now needed to parse the larger buffer, in the case that a call to "ip link" is on the critical time path of an application, (called multiple times in a tight loop, for example), it would affect load.

  [Other Info]

  Observed on Ubuntu kernel 4.4.0-93-generic on both 14.04 and 16.04

  =====================================================================================================
  Ubuntu16 system

  stack at cluster04:~$ lsb_release -a
  No LSB modules are available.
  Distributor ID:	Ubuntu
  Description:	Ubuntu 16.04.3 LTS
  Release:	16.04
  Codename:	xenial

  stack at cluster04:~$ uname -r
  4.4.0-93-generic

  stack at cluster04:~$ apt-cache policy iproute2
  iproute2:
    Installed: 4.3.0-1ubuntu3.16.04.1
  Version table:
  *** 4.3.0-1ubuntu3.16.04.1 500
          500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
  =================================================================================================

  Ubuntu14 system:
  root at boomslang:~# lsb_release -a
  No LSB modules are available.
  Distributor ID:	Ubuntu
  Description:	Ubuntu 14.04.3 LTS
  Release:	14.04
  Codename:	trusty

  root at boomslang:~# uname -r
  4.4.0-96-generic

  root at boomslang:~# apt-cache policy iproute2
  iproute2:
    Installed: 3.12.0-2ubuntu1
    Version table:
   *** 3.12.0-2ubuntu1 0
          500 http://za.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1720126/+subscriptions