** Description changed:
- TBA
+ [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.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1836760
Title:
ixgbe{vf} - Physical Function gets IRQ when VF checks link state
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Status in linux source package in Cosmic:
Confirmed
Status in linux source package in Disco:
Confirmed
Status in linux source package in Eoan:
Confirmed
Status in linux source package in FF-Series:
Fix Released
Bug description:
[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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836760/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
