netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net v2] vmxnet3: update MTU after device quiesce
@ 2025-05-15 19:04 Ronak Doshi
  2025-05-16 23:10 ` patchwork-bot+netdevbpf
  0 siblings, 1 reply; 2+ messages in thread
From: Ronak Doshi @ 2025-05-15 19:04 UTC (permalink / raw)
  To: netdev
  Cc: Ronak Doshi, stable, Guolin Yang,
	Broadcom internal kernel review list, Andrew Lunn,
	David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Ronghua Zhang, Shreyas Bhatewara, Bhavesh Davda, open list

Currently, when device mtu is updated, vmxnet3 updates netdev mtu, quiesces
the device and then reactivates it for the ESXi to know about the new mtu.
So, technically the OS stack can start using the new mtu before ESXi knows
about the new mtu.

This can lead to issues for TSO packets which use mss as per the new mtu
configured. This patch fixes this issue by moving the mtu write after
device quiesce.

Cc: stable@vger.kernel.org
Fixes: d1a890fa37f2 ("net: VMware virtual Ethernet NIC driver: vmxnet3")
Signed-off-by: Ronak Doshi <ronak.doshi@broadcom.com>
Acked-by: Guolin Yang <guolin.yang@broadcom.com>
Changes v1-> v2:
  Moved MTU write after destroy of rx rings
---
 drivers/net/vmxnet3/vmxnet3_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 3df6aabc7e33..c676979c7ab9 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -3607,8 +3607,6 @@ vmxnet3_change_mtu(struct net_device *netdev, int new_mtu)
 	struct vmxnet3_adapter *adapter = netdev_priv(netdev);
 	int err = 0;
 
-	WRITE_ONCE(netdev->mtu, new_mtu);
-
 	/*
 	 * Reset_work may be in the middle of resetting the device, wait for its
 	 * completion.
@@ -3622,6 +3620,7 @@ vmxnet3_change_mtu(struct net_device *netdev, int new_mtu)
 
 		/* we need to re-create the rx queue based on the new mtu */
 		vmxnet3_rq_destroy_all(adapter);
+		WRITE_ONCE(netdev->mtu, new_mtu);
 		vmxnet3_adjust_rx_ring_size(adapter);
 		err = vmxnet3_rq_create_all(adapter);
 		if (err) {
@@ -3638,6 +3637,8 @@ vmxnet3_change_mtu(struct net_device *netdev, int new_mtu)
 				   "Closing it\n", err);
 			goto out;
 		}
+	} else {
+		WRITE_ONCE(netdev->mtu, new_mtu);
 	}
 
 out:
-- 
2.45.2


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

* Re: [PATCH net v2] vmxnet3: update MTU after device quiesce
  2025-05-15 19:04 [PATCH net v2] vmxnet3: update MTU after device quiesce Ronak Doshi
@ 2025-05-16 23:10 ` patchwork-bot+netdevbpf
  0 siblings, 0 replies; 2+ messages in thread
From: patchwork-bot+netdevbpf @ 2025-05-16 23:10 UTC (permalink / raw)
  To: Ronak Doshi
  Cc: netdev, stable, guolin.yang, bcm-kernel-feedback-list,
	andrew+netdev, davem, edumazet, kuba, pabeni, ronghua, sbhatewara,
	bhavesh, linux-kernel

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 15 May 2025 19:04:56 +0000 you wrote:
> Currently, when device mtu is updated, vmxnet3 updates netdev mtu, quiesces
> the device and then reactivates it for the ESXi to know about the new mtu.
> So, technically the OS stack can start using the new mtu before ESXi knows
> about the new mtu.
> 
> This can lead to issues for TSO packets which use mss as per the new mtu
> configured. This patch fixes this issue by moving the mtu write after
> device quiesce.
> 
> [...]

Here is the summary with links:
  - [net,v2] vmxnet3: update MTU after device quiesce
    https://git.kernel.org/netdev/net/c/43f0999af011

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] 2+ messages in thread

end of thread, other threads:[~2025-05-16 23:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-15 19:04 [PATCH net v2] vmxnet3: update MTU after device quiesce Ronak Doshi
2025-05-16 23:10 ` 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).