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 10/13] fm10k: don't loop while resetting VFs due to VFLR event
Date: Mon, 2 Oct 2017 08:42:33 -0700 [thread overview]
Message-ID: <20171002154236.84043-11-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <20171002154236.84043-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
We've always had a really weird looping construction for resetting VFs.
We read the VFLRE register and reset the VF if the corresponding bit is
set, which makes sense. However we loop continuously until we no longer
have any bits left unset. At first this makes sense, as a sort of "keep
trying until we succeed" concept.
Unfortunately this causes a problem if we happen to surprise remove
while this code is executing, because in this case we'll always read all
1s for the VFLRE register. This results in a hard lockup on the CPU
because the loop will never terminate.
Because our own reset function will clear the VFLR event register
always, (except when we've lost PCIe link obviously) there is no real
reason to loop. In practice, we'll loop over once and find that no VFs
are pending anymore.
Lets just check once. Since we're clear the notification when we reset
there's no benefit to the loop. Additionally, there shouldn't be a race
as future VLFRE events should trigger an interrupt. Additionally, we
didn't warn or do anything in the looped case anyways.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
index dfc88a463735..03897720bf0b 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -66,23 +66,21 @@ s32 fm10k_iov_event(struct fm10k_intfc *interface)
goto read_unlock;
/* read VFLRE to determine if any VFs have been reset */
- do {
- vflre = fm10k_read_reg(hw, FM10K_PFVFLRE(1));
- vflre <<= 32;
- vflre |= fm10k_read_reg(hw, FM10K_PFVFLRE(0));
+ vflre = fm10k_read_reg(hw, FM10K_PFVFLRE(1));
+ vflre <<= 32;
+ vflre |= fm10k_read_reg(hw, FM10K_PFVFLRE(0));
- i = iov_data->num_vfs;
+ i = iov_data->num_vfs;
- for (vflre <<= 64 - i; vflre && i--; vflre += vflre) {
- struct fm10k_vf_info *vf_info = &iov_data->vf_info[i];
+ for (vflre <<= 64 - i; vflre && i--; vflre += vflre) {
+ struct fm10k_vf_info *vf_info = &iov_data->vf_info[i];
- if (vflre >= 0)
- continue;
+ if (vflre >= 0)
+ continue;
- hw->iov.ops.reset_resources(hw, vf_info);
- vf_info->mbx.ops.connect(hw, &vf_info->mbx);
- }
- } while (i != iov_data->num_vfs);
+ hw->iov.ops.reset_resources(hw, vf_info);
+ vf_info->mbx.ops.connect(hw, &vf_info->mbx);
+ }
read_unlock:
rcu_read_unlock();
--
2.14.2
next prev parent reply other threads:[~2017-10-02 15:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 15:42 [net-next 00/13][pull request] 100GbE Intel Wired LAN Driver Updates 2017-10-02 Jeff Kirsher
2017-10-02 15:42 ` [net-next 01/13] fm10k: ensure we process SM mbx when processing VF mbx Jeff Kirsher
2017-10-02 15:42 ` [net-next 02/13] fm10k: reschedule service event if we stall the PF<->SM mailbox Jeff Kirsher
2017-10-02 15:42 ` [net-next 03/13] fm10k: Use seq_putc() in fm10k_dbg_desc_break() Jeff Kirsher
2017-10-02 15:42 ` [net-next 04/13] fm10k: stop spurious link down messages when Tx FIFO is full Jeff Kirsher
2017-10-02 15:42 ` [net-next 05/13] fm10k: fix typos on fall through comments Jeff Kirsher
2017-10-02 15:42 ` [net-next 06/13] fm10k: avoid possible truncation of q_vector->name Jeff Kirsher
2017-10-02 15:42 ` [net-next 07/13] fm10k: add missing fall through comment Jeff Kirsher
2017-10-02 15:42 ` [net-next 08/13] fm10k: avoid needless delay when loading driver Jeff Kirsher
2017-10-02 15:42 ` [net-next 09/13] fm10k: simplify reading PFVFLRE register Jeff Kirsher
2017-10-02 15:42 ` Jeff Kirsher [this message]
2017-10-02 15:42 ` [net-next 11/13] fm10k: avoid divide by zero in rare cases when device is resetting Jeff Kirsher
2017-10-02 15:42 ` [net-next 12/13] fm10k: move fm10k_prepare_for_reset and fm10k_handle_reset Jeff Kirsher
2017-10-02 15:42 ` [net-next 13/13] fm10k: prevent race condition of __FM10K_SERVICE_SCHED Jeff Kirsher
2017-10-02 18:59 ` [net-next 00/13][pull request] 100GbE Intel Wired LAN Driver Updates 2017-10-02 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=20171002154236.84043-11-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