From: Jakub Kicinski <kuba@kernel.org>
To: Laurent Vivier <lvivier@redhat.com>
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 08:43:19 -0700 [thread overview]
Message-ID: <20260723084319.40fee97f@kernel.org> (raw)
In-Reply-To: <20260717151626.2913171-1-lvivier@redhat.com>
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.
> 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.)
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)
--
pw-bot: cr
next prev parent reply other threads:[~2026-07-23 15:43 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 [this message]
2026-07-23 17:20 ` Laurent Vivier
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=20260723084319.40fee97f@kernel.org \
--to=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lvivier@redhat.com \
--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