APPLIED[E]: [SRU B/D][SRU X][Unstable][PATCH 0/1] ixgbe{vf} - Physical Function gets IRQ when VF checks link state

[Seth Forshee]

On Tue, Jul 16, 2019 at 05:13:41PM -0300, Guilherme G. Piccoli wrote:
> BugLink: https://bugs.launchpad.net/bugs/1836760
> 
> [Impact]
> 
> * Intel NICs that are SR-IOV capable and are managed by ixgbe driver presents a
> potentially harmful behavior when the ixgbevf-managed VFs (Virtual Functions)
> perform an ethtool link check. The ixgbevf driver issues a mailbox command in
> the ethtool link state handler, which induces one IRQ in the PF (Physical
> Function) per link check.
> 
> * This was reported as a sort of "denial-of-service" from a guest; due to some
> link check loop running inside a guest with PCI-PT of a ixgbevf-managed VF, the
> host received a huge amount of IRQs causing soft-lockups.
> 
> * The patch proposed in this SRU request fix this behavior by relying in the
> saved link state (obtained in the ixgbevf's watchdog routine) instead of issuing
> a mailbox command to the PF in every link state check request. The commit is
> available on Linus tree:
> 1e1b0c658d9b ("ixgbevf: Use cached link state instead of re-reading the value for ethtool")
> http://git.kernel.org/linus/1e1b0c658d9b
> 
> [Test case]
> 
> Reproducing the behavior is pretty simple; having a machine with an Intel NIC
> managed by ixgbe, proceed with the following steps:
> 
> a) Create one or more VFs
> (echo 1 > /sys/class/net/<PF iface>/device/sriov_numvfs)
> 
> b) In a different terminal, monitor the non-TxRx PF IRQs:
> (watch -n1 "cat /proc/interrupts | grep <PF iface> | grep -v Tx")
> 
> c) Run "ethtool <VF iface>" in a loop
> 
> Without the hereby proposed patch, the PF IRQs will increase.
> 
> [Regression potential]
> 
> The patch scope is restricted to ixgbevf ethtool link-check procedure, and was
> developed by the vendor itself. Being a self-contained patch affecting only this
> driver's ethtool handler, the worst potential regression would be a wrong link
> state report.

Applied to eoan/master-next, thanks!