Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19
@ 2021-07-19 16:31 Tony Nguyen
  2021-07-19 16:31 ` [PATCH net-next 1/3] i40e: improve locking of mac_filter_hash Tony Nguyen
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Tony Nguyen @ 2021-07-19 16:31 UTC (permalink / raw)
  To: davem, kuba; +Cc: Tony Nguyen, netdev, sassmann

This series contains updates to iavf and i40e drivers.

Stefan Assmann adds locking to a path that does not acquire a spinlock
where needed for i40e. He also adjusts locking of critical sections to
help avoid races and removes overriding of the adapter state during
pending reset for iavf driver.

The following are changes since commit 0d6835ffe50c9c1f098b5704394331710b67af48:
  net: phy: Fix data type in DP83822 dp8382x_disable_wol()
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 40GbE

Stefan Assmann (3):
  i40e: improve locking of mac_filter_hash
  iavf: do not override the adapter state in the watchdog task
  iavf: fix locking of critical sections

 .../ethernet/intel/i40e/i40e_virtchnl_pf.c    | 23 +++++++-
 drivers/net/ethernet/intel/iavf/iavf_main.c   | 58 ++++++++++++++++---
 2 files changed, 70 insertions(+), 11 deletions(-)

-- 
2.26.2


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH net-next 1/3] i40e: improve locking of mac_filter_hash
  2021-07-19 16:31 [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 Tony Nguyen
@ 2021-07-19 16:31 ` Tony Nguyen
  2021-07-19 16:31 ` [PATCH net-next 2/3] iavf: do not override the adapter state in the watchdog task Tony Nguyen
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 7+ messages in thread
From: Tony Nguyen @ 2021-07-19 16:31 UTC (permalink / raw)
  To: davem, kuba
  Cc: Stefan Assmann, netdev, anthony.l.nguyen, Paolo Abeni, Konrad Jankowski

From: Stefan Assmann <sassmann@kpanic.de>

i40e_config_vf_promiscuous_mode() calls
i40e_getnum_vf_vsi_vlan_filters() without acquiring the
mac_filter_hash_lock spinlock.

This is unsafe because mac_filter_hash may get altered in another thread
while i40e_getnum_vf_vsi_vlan_filters() traverses the hashes.

Simply adding the spinlock in i40e_getnum_vf_vsi_vlan_filters() is not
possible as it already gets called in i40e_get_vlan_list_sync() with the
spinlock held. Therefore adding a wrapper that acquires the spinlock and
call the correct function where appropriate.

Fixes: 37d318d7805f ("i40e: Remove scheduling while atomic possibility")
Fix-suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 .../ethernet/intel/i40e/i40e_virtchnl_pf.c    | 23 ++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index eff0a30790dd..472f56b360b8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1160,12 +1160,12 @@ static int i40e_quiesce_vf_pci(struct i40e_vf *vf)
 }
 
 /**
- * i40e_getnum_vf_vsi_vlan_filters
+ * __i40e_getnum_vf_vsi_vlan_filters
  * @vsi: pointer to the vsi
  *
  * called to get the number of VLANs offloaded on this VF
  **/
-static int i40e_getnum_vf_vsi_vlan_filters(struct i40e_vsi *vsi)
+static int __i40e_getnum_vf_vsi_vlan_filters(struct i40e_vsi *vsi)
 {
 	struct i40e_mac_filter *f;
 	u16 num_vlans = 0, bkt;
@@ -1178,6 +1178,23 @@ static int i40e_getnum_vf_vsi_vlan_filters(struct i40e_vsi *vsi)
 	return num_vlans;
 }
 
+/**
+ * i40e_getnum_vf_vsi_vlan_filters
+ * @vsi: pointer to the vsi
+ *
+ * wrapper for __i40e_getnum_vf_vsi_vlan_filters() with spinlock held
+ **/
+static int i40e_getnum_vf_vsi_vlan_filters(struct i40e_vsi *vsi)
+{
+	int num_vlans;
+
+	spin_lock_bh(&vsi->mac_filter_hash_lock);
+	num_vlans = __i40e_getnum_vf_vsi_vlan_filters(vsi);
+	spin_unlock_bh(&vsi->mac_filter_hash_lock);
+
+	return num_vlans;
+}
+
 /**
  * i40e_get_vlan_list_sync
  * @vsi: pointer to the VSI
@@ -1195,7 +1212,7 @@ static void i40e_get_vlan_list_sync(struct i40e_vsi *vsi, u16 *num_vlans,
 	int bkt;
 
 	spin_lock_bh(&vsi->mac_filter_hash_lock);
-	*num_vlans = i40e_getnum_vf_vsi_vlan_filters(vsi);
+	*num_vlans = __i40e_getnum_vf_vsi_vlan_filters(vsi);
 	*vlan_list = kcalloc(*num_vlans, sizeof(**vlan_list), GFP_ATOMIC);
 	if (!(*vlan_list))
 		goto err;
-- 
2.26.2


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH net-next 2/3] iavf: do not override the adapter state in the watchdog task
  2021-07-19 16:31 [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 Tony Nguyen
  2021-07-19 16:31 ` [PATCH net-next 1/3] i40e: improve locking of mac_filter_hash Tony Nguyen
@ 2021-07-19 16:31 ` Tony Nguyen
  2021-07-19 16:31 ` [PATCH net-next 3/3] iavf: fix locking of critical sections Tony Nguyen
  2021-07-20 13:30 ` [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 patchwork-bot+netdevbpf
  3 siblings, 0 replies; 7+ messages in thread
From: Tony Nguyen @ 2021-07-19 16:31 UTC (permalink / raw)
  To: davem, kuba; +Cc: Stefan Assmann, netdev, anthony.l.nguyen, Konrad Jankowski

From: Stefan Assmann <sassmann@kpanic.de>

The iavf watchdog task overrides adapter->state to __IAVF_RESETTING
when it detects a pending reset. Then schedules iavf_reset_task() which
takes care of the reset.

The reset task is capable of handling the reset without changing
adapter->state. In fact we lose the state information when the watchdog
task prematurely changes the adapter state. This may lead to a crash if
instead of the reset task the iavf_remove() function gets called before
the reset task.
In that case (if we were in state __IAVF_RUNNING previously) the
iavf_remove() function triggers iavf_close() which fails to close the
device because of the incorrect state information.

This may result in a crash due to pending interrupts.
kernel BUG at drivers/pci/msi.c:357!
[...]
Call Trace:
 [<ffffffffbddf24dd>] pci_disable_msix+0x3d/0x50
 [<ffffffffc08d2a63>] iavf_reset_interrupt_capability+0x23/0x40 [iavf]
 [<ffffffffc08d312a>] iavf_remove+0x10a/0x350 [iavf]
 [<ffffffffbddd3359>] pci_device_remove+0x39/0xc0
 [<ffffffffbdeb492f>] __device_release_driver+0x7f/0xf0
 [<ffffffffbdeb49c3>] device_release_driver+0x23/0x30
 [<ffffffffbddcabb4>] pci_stop_bus_device+0x84/0xa0
 [<ffffffffbddcacc2>] pci_stop_and_remove_bus_device+0x12/0x20
 [<ffffffffbddf361f>] pci_iov_remove_virtfn+0xaf/0x160
 [<ffffffffbddf3bcc>] sriov_disable+0x3c/0xf0
 [<ffffffffbddf3ca3>] pci_disable_sriov+0x23/0x30
 [<ffffffffc0667365>] i40e_free_vfs+0x265/0x2d0 [i40e]
 [<ffffffffc0667624>] i40e_pci_sriov_configure+0x144/0x1f0 [i40e]
 [<ffffffffbddd5307>] sriov_numvfs_store+0x177/0x1d0
Code: 00 00 e8 3c 25 e3 ff 49 c7 86 88 08 00 00 00 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 7b 28 e8 0d 44
RIP  [<ffffffffbbbf1068>] free_msi_irqs+0x188/0x190

The solution is to not touch the adapter->state in iavf_watchdog_task()
and let the reset task handle the state transition.

Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/iavf/iavf_main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 44bafedd09f2..44cadf4ebb24 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -1988,7 +1988,6 @@ static void iavf_watchdog_task(struct work_struct *work)
 		/* check for hw reset */
 	reg_val = rd32(hw, IAVF_VF_ARQLEN1) & IAVF_VF_ARQLEN1_ARQENABLE_MASK;
 	if (!reg_val) {
-		adapter->state = __IAVF_RESETTING;
 		adapter->flags |= IAVF_FLAG_RESET_PENDING;
 		adapter->aq_required = 0;
 		adapter->current_op = VIRTCHNL_OP_UNKNOWN;
-- 
2.26.2


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH net-next 3/3] iavf: fix locking of critical sections
  2021-07-19 16:31 [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 Tony Nguyen
  2021-07-19 16:31 ` [PATCH net-next 1/3] i40e: improve locking of mac_filter_hash Tony Nguyen
  2021-07-19 16:31 ` [PATCH net-next 2/3] iavf: do not override the adapter state in the watchdog task Tony Nguyen
@ 2021-07-19 16:31 ` Tony Nguyen
  2021-07-20 11:31   ` Jakub Kicinski
  2021-07-20 13:30 ` [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 patchwork-bot+netdevbpf
  3 siblings, 1 reply; 7+ messages in thread
From: Tony Nguyen @ 2021-07-19 16:31 UTC (permalink / raw)
  To: davem, kuba; +Cc: Stefan Assmann, netdev, anthony.l.nguyen, Konrad Jankowski

From: Stefan Assmann <sassmann@kpanic.de>

To avoid races between iavf_init_task(), iavf_reset_task(),
iavf_watchdog_task(), iavf_adminq_task() as well as the shutdown and
remove functions more locking is required.
The current protection by __IAVF_IN_CRITICAL_TASK is needed in
additional places.

- The reset task performs state transitions, therefore needs locking.
- The adminq task acts on replies from the PF in
  iavf_virtchnl_completion() which may alter the states.
- The init task is not only run during probe but also if a VF gets stuck
  to reinitialize it.
- The shutdown function performs a state transition.
- The remove function performs a state transition and also free's
  resources.

iavf_lock_timeout() is introduced to avoid waiting infinitely
and cause a deadlock. Rather unlock and print a warning.

Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/iavf/iavf_main.c | 57 ++++++++++++++++++---
 1 file changed, 50 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 44cadf4ebb24..fa6cf20da911 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -131,6 +131,30 @@ enum iavf_status iavf_free_virt_mem_d(struct iavf_hw *hw,
 	return 0;
 }
 
+/**
+ * iavf_lock_timeout - try to set bit but give up after timeout
+ * @adapter: board private structure
+ * @bit: bit to set
+ * @msecs: timeout in msecs
+ *
+ * Returns 0 on success, negative on failure
+ **/
+static int iavf_lock_timeout(struct iavf_adapter *adapter,
+			     enum iavf_critical_section_t bit,
+			     unsigned int msecs)
+{
+	unsigned int wait, delay = 10;
+
+	for (wait = 0; wait < msecs; wait += delay) {
+		if (!test_and_set_bit(bit, &adapter->crit_section))
+			return 0;
+
+		msleep(delay);
+	}
+
+	return -1;
+}
+
 /**
  * iavf_schedule_reset - Set the flags and schedule a reset event
  * @adapter: board private structure
@@ -2101,6 +2125,10 @@ static void iavf_reset_task(struct work_struct *work)
 	if (test_bit(__IAVF_IN_REMOVE_TASK, &adapter->crit_section))
 		return;
 
+	if (iavf_lock_timeout(adapter, __IAVF_IN_CRITICAL_TASK, 200)) {
+		schedule_work(&adapter->reset_task);
+		return;
+	}
 	while (test_and_set_bit(__IAVF_IN_CLIENT_TASK,
 				&adapter->crit_section))
 		usleep_range(500, 1000);
@@ -2307,6 +2335,8 @@ static void iavf_adminq_task(struct work_struct *work)
 	if (!event.msg_buf)
 		goto out;
 
+	if (iavf_lock_timeout(adapter, __IAVF_IN_CRITICAL_TASK, 200))
+		goto freedom;
 	do {
 		ret = iavf_clean_arq_element(hw, &event, &pending);
 		v_op = (enum virtchnl_ops)le32_to_cpu(event.desc.cookie_high);
@@ -2320,6 +2350,7 @@ static void iavf_adminq_task(struct work_struct *work)
 		if (pending != 0)
 			memset(event.msg_buf, 0, IAVF_MAX_AQ_BUF_SIZE);
 	} while (pending);
+	clear_bit(__IAVF_IN_CRITICAL_TASK, &adapter->crit_section);
 
 	if ((adapter->flags &
 	     (IAVF_FLAG_RESET_PENDING | IAVF_FLAG_RESET_NEEDED)) ||
@@ -3624,6 +3655,10 @@ static void iavf_init_task(struct work_struct *work)
 						    init_task.work);
 	struct iavf_hw *hw = &adapter->hw;
 
+	if (iavf_lock_timeout(adapter, __IAVF_IN_CRITICAL_TASK, 5000)) {
+		dev_warn(&adapter->pdev->dev, "failed to set __IAVF_IN_CRITICAL_TASK in %s\n", __FUNCTION__);
+		return;
+	}
 	switch (adapter->state) {
 	case __IAVF_STARTUP:
 		if (iavf_startup(adapter) < 0)
@@ -3636,14 +3671,14 @@ static void iavf_init_task(struct work_struct *work)
 	case __IAVF_INIT_GET_RESOURCES:
 		if (iavf_init_get_resources(adapter) < 0)
 			goto init_failed;
-		return;
+		goto out;
 	default:
 		goto init_failed;
 	}
 
 	queue_delayed_work(iavf_wq, &adapter->init_task,
 			   msecs_to_jiffies(30));
-	return;
+	goto out;
 init_failed:
 	if (++adapter->aq_wait_count > IAVF_AQ_MAX_ERR) {
 		dev_err(&adapter->pdev->dev,
@@ -3652,9 +3687,11 @@ static void iavf_init_task(struct work_struct *work)
 		iavf_shutdown_adminq(hw);
 		adapter->state = __IAVF_STARTUP;
 		queue_delayed_work(iavf_wq, &adapter->init_task, HZ * 5);
-		return;
+		goto out;
 	}
 	queue_delayed_work(iavf_wq, &adapter->init_task, HZ);
+out:
+	clear_bit(__IAVF_IN_CRITICAL_TASK, &adapter->crit_section);
 }
 
 /**
@@ -3671,9 +3708,12 @@ static void iavf_shutdown(struct pci_dev *pdev)
 	if (netif_running(netdev))
 		iavf_close(netdev);
 
+	if (iavf_lock_timeout(adapter, __IAVF_IN_CRITICAL_TASK, 5000))
+		dev_warn(&adapter->pdev->dev, "failed to set __IAVF_IN_CRITICAL_TASK in %s\n", __FUNCTION__);
 	/* Prevent the watchdog from running. */
 	adapter->state = __IAVF_REMOVE;
 	adapter->aq_required = 0;
+	clear_bit(__IAVF_IN_CRITICAL_TASK, &adapter->crit_section);
 
 #ifdef CONFIG_PM
 	pci_save_state(pdev);
@@ -3907,10 +3947,6 @@ static void iavf_remove(struct pci_dev *pdev)
 				 err);
 	}
 
-	/* Shut down all the garbage mashers on the detention level */
-	adapter->state = __IAVF_REMOVE;
-	adapter->aq_required = 0;
-	adapter->flags &= ~IAVF_FLAG_REINIT_ITR_NEEDED;
 	iavf_request_reset(adapter);
 	msleep(50);
 	/* If the FW isn't responding, kick it once, but only once. */
@@ -3918,6 +3954,13 @@ static void iavf_remove(struct pci_dev *pdev)
 		iavf_request_reset(adapter);
 		msleep(50);
 	}
+	if (iavf_lock_timeout(adapter, __IAVF_IN_CRITICAL_TASK, 5000))
+		dev_warn(&adapter->pdev->dev, "failed to set __IAVF_IN_CRITICAL_TASK in %s\n", __FUNCTION__);
+
+	/* Shut down all the garbage mashers on the detention level */
+	adapter->state = __IAVF_REMOVE;
+	adapter->aq_required = 0;
+	adapter->flags &= ~IAVF_FLAG_REINIT_ITR_NEEDED;
 	iavf_free_all_tx_resources(adapter);
 	iavf_free_all_rx_resources(adapter);
 	iavf_misc_irq_disable(adapter);
-- 
2.26.2


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next 3/3] iavf: fix locking of critical sections
  2021-07-19 16:31 ` [PATCH net-next 3/3] iavf: fix locking of critical sections Tony Nguyen
@ 2021-07-20 11:31   ` Jakub Kicinski
  2021-07-20 12:03     ` Stefan Assmann
  0 siblings, 1 reply; 7+ messages in thread
From: Jakub Kicinski @ 2021-07-20 11:31 UTC (permalink / raw)
  To: Tony Nguyen; +Cc: davem, Stefan Assmann, netdev, Konrad Jankowski

On Mon, 19 Jul 2021 09:31:54 -0700, Tony Nguyen wrote:
> To avoid races between iavf_init_task(), iavf_reset_task(),
> iavf_watchdog_task(), iavf_adminq_task() as well as the shutdown and
> remove functions more locking is required.
> The current protection by __IAVF_IN_CRITICAL_TASK is needed in
> additional places.
> 
> - The reset task performs state transitions, therefore needs locking.
> - The adminq task acts on replies from the PF in
>   iavf_virtchnl_completion() which may alter the states.
> - The init task is not only run during probe but also if a VF gets stuck
>   to reinitialize it.
> - The shutdown function performs a state transition.
> - The remove function performs a state transition and also free's
>   resources.
> 
> iavf_lock_timeout() is introduced to avoid waiting infinitely
> and cause a deadlock. Rather unlock and print a warning.

I have a vague recollection of complaining about something like this
previously. Why not use a normal lock? Please at the very least include
an explanation in the commit message.

If you use bit locks you should use the _lock and _unlock flavours of
the bitops.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next 3/3] iavf: fix locking of critical sections
  2021-07-20 11:31   ` Jakub Kicinski
@ 2021-07-20 12:03     ` Stefan Assmann
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Assmann @ 2021-07-20 12:03 UTC (permalink / raw)
  To: Jakub Kicinski, Tony Nguyen; +Cc: davem, netdev, Konrad Jankowski

On 20.07.21 13:31, Jakub Kicinski wrote:
> On Mon, 19 Jul 2021 09:31:54 -0700, Tony Nguyen wrote:
>> To avoid races between iavf_init_task(), iavf_reset_task(),
>> iavf_watchdog_task(), iavf_adminq_task() as well as the shutdown and
>> remove functions more locking is required.
>> The current protection by __IAVF_IN_CRITICAL_TASK is needed in
>> additional places.
>>
>> - The reset task performs state transitions, therefore needs locking.
>> - The adminq task acts on replies from the PF in
>>   iavf_virtchnl_completion() which may alter the states.
>> - The init task is not only run during probe but also if a VF gets stuck
>>   to reinitialize it.
>> - The shutdown function performs a state transition.
>> - The remove function performs a state transition and also free's
>>   resources.
>>
>> iavf_lock_timeout() is introduced to avoid waiting infinitely
>> and cause a deadlock. Rather unlock and print a warning.
> 
> I have a vague recollection of complaining about something like this
> previously. Why not use a normal lock? Please at the very least include
> an explanation in the commit message.
> 
> If you use bit locks you should use the _lock and _unlock flavours of
> the bitops.
> 

Hi Jakub,

yes you remember correctly, back then we agreed to fix this afterwards.
It's not been forgotten, working on the conversion is the next step.

Thanks!

  Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19
  2021-07-19 16:31 [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 Tony Nguyen
                   ` (2 preceding siblings ...)
  2021-07-19 16:31 ` [PATCH net-next 3/3] iavf: fix locking of critical sections Tony Nguyen
@ 2021-07-20 13:30 ` patchwork-bot+netdevbpf
  3 siblings, 0 replies; 7+ messages in thread
From: patchwork-bot+netdevbpf @ 2021-07-20 13:30 UTC (permalink / raw)
  To: Tony Nguyen; +Cc: davem, kuba, netdev, sassmann

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Mon, 19 Jul 2021 09:31:51 -0700 you wrote:
> This series contains updates to iavf and i40e drivers.
> 
> Stefan Assmann adds locking to a path that does not acquire a spinlock
> where needed for i40e. He also adjusts locking of critical sections to
> help avoid races and removes overriding of the adapter state during
> pending reset for iavf driver.
> 
> [...]

Here is the summary with links:
  - [net-next,1/3] i40e: improve locking of mac_filter_hash
    https://git.kernel.org/netdev/net-next/c/8b4b06919fd6
  - [net-next,2/3] iavf: do not override the adapter state in the watchdog task
    https://git.kernel.org/netdev/net-next/c/22c8fd71d3a5
  - [net-next,3/3] iavf: fix locking of critical sections
    https://git.kernel.org/netdev/net-next/c/226d528512cf

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-07-20 13:35 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-19 16:31 [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 Tony Nguyen
2021-07-19 16:31 ` [PATCH net-next 1/3] i40e: improve locking of mac_filter_hash Tony Nguyen
2021-07-19 16:31 ` [PATCH net-next 2/3] iavf: do not override the adapter state in the watchdog task Tony Nguyen
2021-07-19 16:31 ` [PATCH net-next 3/3] iavf: fix locking of critical sections Tony Nguyen
2021-07-20 11:31   ` Jakub Kicinski
2021-07-20 12:03     ` Stefan Assmann
2021-07-20 13:30 ` [PATCH net-next 0/3][pull request] 40GbE Intel Wired LAN Driver Updates 2021-07-19 patchwork-bot+netdevbpf

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).