From: Jiri Benc <jbenc@redhat.com>
To: Ren Wei <n05ec@lzu.edu.cn>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
yuantan098@gmail.com, yifanwucs@gmail.com,
tomapufckgml@gmail.com, bird@lzu.edu.cn, lx24@stu.ynu.edu.cn,
caoruide123@gmail.com
Subject: Re: [PATCH net 1/1] net: nsh: handle nested NSH headers during GSO
Date: Wed, 22 Apr 2026 10:52:42 +0200 [thread overview]
Message-ID: <20260422105242.7b28f72c@griffin> (raw)
In-Reply-To: <6112cce99b4e3571444a616d0fb19e91e2fcca72.1776597598.git.caoruide123@gmail.com>
On Mon, 20 Apr 2026 11:31:32 +0800, Ren Wei wrote:
> Handle nested NSH headers iteratively in a single nsh_gso_segment()
> invocation. Unwrap consecutive NSH headers until the first non-NSH payload
> is reached, including the case where the next redispatch target is reached
> through ETH_P_TEB, segment that payload once, and then restore the full
> outer encapsulation on each output segment.
This looks fragile. If there's ever another protocol with similar logic
added, we'll be in the same situation. (And obviously, unrolling the
recursion for any combination of protocols doesn't scale well.)
What about using a mechanism similar to dev_xmit_recursion to limit the
depth and returning EINVAL if we exceed the limit? I think it's fine to
drop the packet in this pathological case.
We might even just use dev_xmit_recursion directly, since it can be
argued that such nested NSH headers are in fact nested tunnels.
Jiri
prev parent reply other threads:[~2026-04-22 8:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1776597597.git.caoruide123@gmail.com>
2026-04-20 3:31 ` [PATCH net 1/1] net: nsh: handle nested NSH headers during GSO Ren Wei
2026-04-20 8:12 ` [syzbot ci] " syzbot ci
2026-04-22 8:52 ` Jiri Benc [this message]
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=20260422105242.7b28f72c@griffin \
--to=jbenc@redhat.com \
--cc=bird@lzu.edu.cn \
--cc=caoruide123@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=lx24@stu.ynu.edu.cn \
--cc=n05ec@lzu.edu.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox