netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
	jogreene@redhat.com, Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: [net-next v2 02/15] i40evf: don't rely on netif_running() outside rtnl_lock()
Date: Tue,  9 Jan 2018 08:19:17 -0800	[thread overview]
Message-ID: <20180109161930.75657-3-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <20180109161930.75657-1-jeffrey.t.kirsher@intel.com>

From: Jacob Keller <jacob.e.keller@intel.com>

In i40evf_reset_task we use netif_running() to determine whether or not
the device is currently up. This allows us to properly free queue memory
and shut down things before we request the hardware reset.

It turns out that we cannot be guaranteed of netif_running() returning
false until the device is fully up, as the kernel core code sets
__LINK_STATE_START prior to calling .ndo_open. Since we're not holding
the rtnl_lock(), it's possible that the driver's i40evf_open handler
function is currently being called while we're resetting.

We can't simply hold the rtnl_lock() while checking netif_running() as
this could cause a deadlock with the i40evf_open() function.
Additionally, we can't avoid the deadlock by holding the rtnl_lock()
over the whole reset path, as this essentially serializes all resets,
and can cause massive delays if we have multiple VFs on a system.

Instead, lets just check our own internal state __I40EVF_RUNNING state
field. This allows us to ensure that the state is correct and is only
set after we've finished bringing the device up.

Without this change we might free data structures about device queues
and other memory before they've been fully allocated.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40evf/i40evf_main.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 7b2a4eba92e2..0b23bf6d7873 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1796,7 +1796,11 @@ static void i40evf_disable_vf(struct i40evf_adapter *adapter)
 
 	adapter->flags |= I40EVF_FLAG_PF_COMMS_FAILED;
 
-	if (netif_running(adapter->netdev)) {
+	/* We don't use netif_running() because it may be true prior to
+	 * ndo_open() returning, so we can't assume it means all our open
+	 * tasks have finished, since we're not holding the rtnl_lock here.
+	 */
+	if (adapter->state == __I40EVF_RUNNING) {
 		set_bit(__I40E_VSI_DOWN, adapter->vsi.state);
 		netif_carrier_off(adapter->netdev);
 		netif_tx_disable(adapter->netdev);
@@ -1854,6 +1858,7 @@ static void i40evf_reset_task(struct work_struct *work)
 	struct i40evf_mac_filter *f;
 	u32 reg_val;
 	int i = 0, err;
+	bool running;
 
 	while (test_and_set_bit(__I40EVF_IN_CLIENT_TASK,
 				&adapter->crit_section))
@@ -1913,7 +1918,13 @@ static void i40evf_reset_task(struct work_struct *work)
 	}
 
 continue_reset:
-	if (netif_running(netdev)) {
+	/* We don't use netif_running() because it may be true prior to
+	 * ndo_open() returning, so we can't assume it means all our open
+	 * tasks have finished, since we're not holding the rtnl_lock here.
+	 */
+	running = (adapter->state == __I40EVF_RUNNING);
+
+	if (running) {
 		netif_carrier_off(netdev);
 		netif_tx_stop_all_queues(netdev);
 		adapter->link_up = false;
@@ -1964,7 +1975,10 @@ static void i40evf_reset_task(struct work_struct *work)
 
 	mod_timer(&adapter->watchdog_timer, jiffies + 2);
 
-	if (netif_running(adapter->netdev)) {
+	/* We were running when the reset started, so we need to restore some
+	 * state here.
+	 */
+	if (running) {
 		/* allocate transmit descriptors */
 		err = i40evf_setup_all_tx_resources(adapter);
 		if (err)
-- 
2.15.1

  parent reply	other threads:[~2018-01-09 16:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 16:19 [net-next v2 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2018-01-09 Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 01/15] i40e: display priority_xon and priority_xoff stats Jeff Kirsher
2018-01-09 16:19 ` Jeff Kirsher [this message]
2018-01-09 16:19 ` [net-next v2 03/15] i40evf: use spinlock to protect (mac|vlan)_filter_list Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 04/15] i40evf: release bit locks in reverse order Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 05/15] i40evf: hold the critical task bit lock while opening Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 06/15] i40e: update VFs of link state after GET_VF_RESOURCES Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 07/15] i40e: add helper conversion function for link_speed Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 08/15] i40e/i40evf: Bump driver versions Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 09/15] i40e: remove redundant initialization of read_size Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 10/15] i40evf: Do not clear MSI-X PBA manually Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 11/15] i40evf: Clean-up flags for promisc mode to avoid high polling rate Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 12/15] i40evf: Drop i40evf_fire_sw_int as it is prone to races Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 13/15] i40e: change ppp name to ddp Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 14/15] i40e: track id can be 0 Jeff Kirsher
2018-01-09 16:19 ` [net-next v2 15/15] i40e: link_down_on_close private flag support Jeff Kirsher
2018-01-10  6:40   ` Jakub Kicinski
2018-01-10  9:33     ` Stachura, Mariusz
2018-01-23 10:55       ` Stachura, Mariusz
2018-01-23 19:38         ` Jakub Kicinski
2018-01-24 13:54           ` Stachura, Mariusz
2018-01-24 21:01             ` Jakub Kicinski
2018-01-10 19:45 ` [net-next v2 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2018-01-09 David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180109161930.75657-3-jeffrey.t.kirsher@intel.com \
    --to=jeffrey.t.kirsher@intel.com \
    --cc=davem@davemloft.net \
    --cc=jacob.e.keller@intel.com \
    --cc=jogreene@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=sassmann@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).