From: Jakub Kicinski <kuba@kernel.org>
To: Subash Abhinov Kasiviswanathan
<subash.a.kasiviswanathan@oss.qualcomm.com>
Cc: sean.tranchetti@oss.qualcomm.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4] net: qualcomm: rmnet: Update MTU handling during format changes
Date: Thu, 12 Nov 2026 08:33:11 -0800 [thread overview]
Message-ID: <20261112083311.641a2216@kernel.org> (raw)
In-Reply-To: <20261108075727.2031331-1-subash.a.kasiviswanathan@oss.qualcomm.com>
On Sat, 7 Nov 2026 23:57:27 -0800 Subash Abhinov Kasiviswanathan wrote:
> rmnet derives the MTU of its devices from the real device MTU minus the
> headroom needed by the egress data format. Several problems exist in
> how this is handled when the data format is set or changed:
>
> - The headroom only accounts for the V4 egress checksum header and
> ignores the V5 one, so devices using V5 checksum offload get an MTU
> that is too large for the real device.
> - rmnet_newlink() sizes the first device from the port's data format
> before the requested IFLA_RMNET_FLAGS have been applied, so the MTU
> does not match the format that ends up being used.
> - A real device MTU smaller than the headroom underflows the unsigned
> subtraction, and a real device with a jumbo MTU makes the creation of
> the first device fail while resizing an existing one clamps it.
> - Existing endpoints are shrunk by writing dev->mtu directly. No MTU
> notifiers run and userspace gets no link notification. The helper
> also returns -1, and changelink flattens every failure into -EINVAL.
> - rmnet_changelink() publishes the new data format before resizing the
> endpoints and reverts it on failure, so the datapath can observe a
> format whose headers do not fit the MTUs. A failed resize can also
> leave some endpoints shrunk, and a mux_id change requested in the
> same call is kept even though the call returned an error.
>
> Fix these by calculating the headroom from the requested data format,
These should probably be 5 separate fixes in a patch series?
next prev parent reply other threads:[~2026-11-12 16:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 7:57 [PATCH net v4] net: qualcomm: rmnet: Update MTU handling during format changes Subash Abhinov Kasiviswanathan
2026-11-08 8:02 ` netdev-bot+sinfo
2026-11-08 8:11 ` subash.a.kasiviswanathan
2026-11-12 16:33 ` Jakub Kicinski
2026-11-12 16:33 ` Jakub Kicinski [this message]
2026-11-12 18:25 ` subash.a.kasiviswanathan
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=20261112083311.641a2216@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sean.tranchetti@oss.qualcomm.com \
--cc=subash.a.kasiviswanathan@oss.qualcomm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.