From: Laurent Vivier <lvivier@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, Stefano Brivio <sbrivio@redhat.com>,
Oliver Neukum <oneukum@suse.com>,
stable@vger.kernel.org
Subject: Re: [PATCH net] usbnet: cap max_mtu for drivers without bind callback
Date: Thu, 23 Jul 2026 19:20:30 +0200 [thread overview]
Message-ID: <ce31de54-d46c-4738-909c-91ef229b7d9e@redhat.com> (raw)
In-Reply-To: <20260723084319.40fee97f@kernel.org>
On 7/23/26 17:43, Jakub Kicinski wrote:
> On Fri, 17 Jul 2026 17:16:26 +0200 Laurent Vivier wrote:
>> Commit c7159e960f14 ("usbnet: limit max_mtu based on device's hard_mtu")
>> caps max_mtu inside the if (info->bind) block in usbnet_probe().
>
> Okay... but before that commit the logic was also missing,
> and that commit only refines the condition. I don't think
> that's the right commit for Fixes.
So it's:
Fixes: f77f0aee4da4 ("net: use core MTU range checking in USB NIC drivers")
Cc: jarod@redhat.com
>
>> Drivers without a bind callback never enter this block, so max_mtu
>> stays at ETH_MAX_MTU.
>>
>> QEMU's usb-net device (0x0525/0xa4a2) is claimed by the cdc_subset
>> driver which has no bind callback. The guest accepts any MTU from DHCP
>> (e.g. 65520 from passt), leading to TCP segments that exceed the
>> device's 2048-byte receive buffer and are silently dropped.
>>
>> Move the max_mtu capping after the if/else block so it applies to all
>> usbnet drivers.
>
> A short explanation here why the changes was made under the bind would
> be quite useful (presumably it was done there because that's where the
> existing MTU check was, and the existing MTU check only mattered if the
> device specific callback could modify the state etc.)
Yes, I put max_mtu here because the existing mtu check was here.
>
> It feels like we should update the max_mtu instead of capping it later
> for devices without bind (note that only a device with bind sets
> NOMAXMTU, too)
What do you think of:
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 25518635b7b7..9ec038a1b6f5 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1794,7 +1794,7 @@ usbnet_probe(struct usb_interface *udev, const struct usb_device_id
*prod)
*/
dev->hard_mtu = net->mtu + net->hard_header_len;
net->min_mtu = 0;
- net->max_mtu = ETH_MAX_MTU;
+ net->max_mtu = dev->hard_mtu - net->hard_header_len;
net->netdev_ops = &usbnet_netdev_ops;
net->watchdog_timeo = TX_TIMEOUT_JIFFIES;
@@ -1825,8 +1825,9 @@ usbnet_probe(struct usb_interface *udev, const struct usb_device_id
*prod)
if ((dev->driver_info->flags & FLAG_NOARP) != 0)
net->flags |= IFF_NOARP;
- if ((dev->driver_info->flags & FLAG_NOMAXMTU) == 0 &&
- net->max_mtu > (dev->hard_mtu - net->hard_header_len))
+ if (dev->driver_info->flags & FLAG_NOMAXMTU) == 0)
+ net->max_mtu = ETH_MAX_MTU;
+ else
net->max_mtu = dev->hard_mtu - net->hard_header_len;
if (net->mtu > (dev->hard_mtu - net->hard_header_len))
Thanks,
Laurent
next prev parent reply other threads:[~2026-07-23 17:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 15:16 [PATCH net] usbnet: cap max_mtu for drivers without bind callback Laurent Vivier
2026-07-23 15:43 ` Jakub Kicinski
2026-07-23 17:20 ` Laurent Vivier [this message]
2026-07-23 18:42 ` Jakub Kicinski
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=ce31de54-d46c-4738-909c-91ef229b7d9e@redhat.com \
--to=lvivier@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=sbrivio@redhat.com \
--cc=stable@vger.kernel.org \
/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