[Intel-wired-lan] [net PATCH v1] i40e: fix recursive rtnl lock

[Intel-wired-lan] [net PATCH v1] i40e: fix recursive rtnl lock

[Jesse Brandeburg]

From: Anjali Singhai Jain <anjali.singhai@intel.com>

The sync_vsi_filters function can be called directly under RTNL
or through the timer subtask without one.  This was causing
a deadlock.

If sync_vsi_filter is called from a thread which held the lock,
and in another thread the PROMISC setting got changed we would be
executing the PROMISC change in the thread which already held the
lock alongside the other filter update. The PROMISC change
requires a reset if we are on a VEB, which requires it to be
called under RTNL.

Earlier the driver would call reset for PROMISC change without
checking if we were already under RTNL and would try to grab
it causing a deadlock. This patch changes the flow to see if we
are already under RTNL before trying to grab it.

Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Kiran Patil <kiran.patil@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 3410fb3..7557c02 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -5340,9 +5340,13 @@ exit:
  **/
 void i40e_do_reset_safe(struct i40e_pf *pf, u32 reset_flags)
 {
-	rtnl_lock();
-	i40e_do_reset(pf, reset_flags);
-	rtnl_unlock();
+	if (!rtnl_is_locked()) {
+		rtnl_lock();
+		i40e_do_reset(pf, reset_flags);
+		rtnl_unlock();
+	} else {
+		i40e_do_reset(pf, reset_flags);
+	}
 }
 
 /**
-- 
2.4.3

[Intel-wired-lan] [net PATCH v1] i40e: fix recursive rtnl lock

[Jesse Brandeburg]

On Thu, 24 Sep 2015 12:20:42 -0700
Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:

> From: Anjali Singhai Jain <anjali.singhai@intel.com>
> 
> The sync_vsi_filters function can be called directly under RTNL
> or through the timer subtask without one.  This was causing
> a deadlock.

This patch was briefly tested, and does actually fix the bug it was
meant to fix, but this patch may cause bugs, one we thought of today was
if another thread grabs the RTNL, this patch will act as if it has it.

Another possible bug is that if another thread had the RTNL, it may
release it while this patch's thread is not completed all the way.

We are working on a further patch/refinement.

[Intel-wired-lan] [net PATCH v1] i40e: fix recursive rtnl lock

[Jesse Brandeburg]

On Fri, 25 Sep 2015 15:45:52 -0700
Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:

> On Thu, 24 Sep 2015 12:20:42 -0700
> Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> 
> > From: Anjali Singhai Jain <anjali.singhai@intel.com>
> > 
> > The sync_vsi_filters function can be called directly under RTNL
> > or through the timer subtask without one.  This was causing
> > a deadlock.
> 
> This patch was briefly tested, and does actually fix the bug it was
> meant to fix, but this patch may cause bugs, one we thought of today was
> if another thread grabs the RTNL, this patch will act as if it has it.
> 
> Another possible bug is that if another thread had the RTNL, it may
> release it while this patch's thread is not completed all the way.
> 
> We are working on a further patch/refinement.

Please drop this patch.