[SRU][B/D/E/F][PATCH 0/1] i40e: Setting VF MAC address causes General Protection Fault

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[SRU][B/D/E/F][PATCH 0/1] i40e: Setting VF MAC address causes General Protection Fault

Heitor Alves de Siqueira
BugLink: https://bugs.launchpad.net/bugs/1852432

[Impact]
 * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and
   leave system unusable

[Test Case]
 * Continuously spin up VFs and set MAC address with e.g. ifconfig

[Fix]
 * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if
   the adapter is still in reset, preventing the GPF.

[Regression Potential]
 * Regression potential should be low, as we're now updating the VSI using the
   ID stored in the VF pointer
 * Regressions could arise from issues in VF creation or reset, as that would
   corrupt the new VSI pointer
 * Patch was validated and tested in a production environment

Slawomir Laba (1):
  i40e: Fix crash caused by stress setting of VF MAC addresses

 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--
2.23.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU][B/D/E/F][PATCH 1/1] i40e: Fix crash caused by stress setting of VF MAC addresses

Heitor Alves de Siqueira
From: Slawomir Laba <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1852432

Add update to the VSI pointer passed to the i40e_set_vf_mac function.
If VF is in reset state the driver waits in i40e_set_vf_mac function
for the reset to be complete, yet after reset the vsi pointer
that was passed into this function is no longer valid.

The patch updates local VSI pointer directly from pf->vsi array,
by using the id stored in VF pointer (lan_vsi_idx).

Without this commit the driver might occasionally invoke general
protection fault in kernel and disable the OS entirely.

Signed-off-by: Slawomir Laba <[hidden email]>
Tested-by: Andrew Bowers <[hidden email]>
Signed-off-by: Jeff Kirsher <[hidden email]>
(cherry picked from commit 9889707b06acfe9bb37a6edcaae627d4a5eacc72)
Signed-off-by: Heitor Alves de Siqueira <[hidden email]>
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 4601f9e4e998..f8aa4deceb5e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -3967,10 +3967,15 @@ int i40e_ndo_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac)
  /* When the VF is resetting wait until it is done.
  * It can take up to 200 milliseconds,
  * but wait for up to 300 milliseconds to be safe.
+ * If the VF is indeed in reset, the vsi pointer has
+ * to show on the newly loaded vsi under pf->vsi[id].
  */
  for (i = 0; i < 15; i++) {
- if (test_bit(I40E_VF_STATE_INIT, &vf->vf_states))
+ if (test_bit(I40E_VF_STATE_INIT, &vf->vf_states)) {
+ if (i > 0)
+ vsi = pf->vsi[vf->lan_vsi_idx];
  break;
+ }
  msleep(20);
  }
  if (!test_bit(I40E_VF_STATE_INIT, &vf->vf_states)) {
--
2.23.0


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [SRU][B/D/E/F][PATCH 0/1] i40e: Setting VF MAC address causes General Protection Fault

Sultan Alsawaf
In reply to this post by Heitor Alves de Siqueira
On Wed, Nov 13, 2019 at 10:39:16AM -0300, Heitor Alves de Siqueira wrote:

> BugLink: https://bugs.launchpad.net/bugs/1852432
>
> [Impact]
>  * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and
>    leave system unusable
>
> [Test Case]
>  * Continuously spin up VFs and set MAC address with e.g. ifconfig
>
> [Fix]
>  * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if
>    the adapter is still in reset, preventing the GPF.
>
> [Regression Potential]
>  * Regression potential should be low, as we're now updating the VSI using the
>    ID stored in the VF pointer
>  * Regressions could arise from issues in VF creation or reset, as that would
>    corrupt the new VSI pointer
>  * Patch was validated and tested in a production environment
>
> Slawomir Laba (1):
>   i40e: Fix crash caused by stress setting of VF MAC addresses
>
>  drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> --
> 2.23.0
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

Acked-by: Sultan Alsawaf <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [SRU][B/D/E/F][PATCH 0/1] i40e: Setting VF MAC address causes General Protection Fault

Kamal Mostafa-2
In reply to this post by Heitor Alves de Siqueira
LGTM.

Acked-by: Kamal Mostafa <[hidden email]>

 -Kamal

On Wed, Nov 13, 2019 at 10:39:16AM -0300, Heitor Alves de Siqueira wrote:

> BugLink: https://bugs.launchpad.net/bugs/1852432
>
> [Impact]
>  * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and
>    leave system unusable
>
> [Test Case]
>  * Continuously spin up VFs and set MAC address with e.g. ifconfig
>
> [Fix]
>  * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if
>    the adapter is still in reset, preventing the GPF.
>
> [Regression Potential]
>  * Regression potential should be low, as we're now updating the VSI using the
>    ID stored in the VF pointer
>  * Regressions could arise from issues in VF creation or reset, as that would
>    corrupt the new VSI pointer
>  * Patch was validated and tested in a production environment
>
> Slawomir Laba (1):
>   i40e: Fix crash caused by stress setting of VF MAC addresses
>
>  drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> --
> 2.23.0
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED(B,D,E): [SRU][B/D/E/F][PATCH 0/1] i40e: Setting VF MAC address causes General Protection Fault

Khaled Elmously
In reply to this post by Heitor Alves de Siqueira
On 2019-11-13 10:39:16 , Heitor Alves de Siqueira wrote:

> BugLink: https://bugs.launchpad.net/bugs/1852432
>
> [Impact]
>  * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and
>    leave system unusable
>
> [Test Case]
>  * Continuously spin up VFs and set MAC address with e.g. ifconfig
>
> [Fix]
>  * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if
>    the adapter is still in reset, preventing the GPF.
>
> [Regression Potential]
>  * Regression potential should be low, as we're now updating the VSI using the
>    ID stored in the VF pointer
>  * Regressions could arise from issues in VF creation or reset, as that would
>    corrupt the new VSI pointer
>  * Patch was validated and tested in a production environment
>
> Slawomir Laba (1):
>   i40e: Fix crash caused by stress setting of VF MAC addresses
>
>  drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> --
> 2.23.0
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team