From: Ido Schimmel <idosch@nvidia.com>
To: Justin Iurman <justin.iurman@gmail.com>, daniel@iogearbox.net
Cc: kuba@kernel.org, edumazet@google.com, dsahern@kernel.org,
tom@herbertland.com, willemdebruijn.kernel@gmail.com,
pabeni@redhat.com, netdev@vger.kernel.org
Subject: Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim
Date: Sun, 19 Apr 2026 17:31:37 +0300 [thread overview]
Message-ID: <20260419143137.GA885197@shredder> (raw)
In-Reply-To: <8fdf517b-6217-4df6-8adf-0c79ce8d3be8@gmail.com>
On Sun, Apr 19, 2026 at 12:37:35AM +0200, Justin Iurman wrote:
> Nope. But if it happens, users would be confused as max_dst_opts_cnt would
> not have the same meaning in two different code paths. OTOH, I agree that
> such situation would look suspicious. I guess it's fine to keep your patch
> as is and to not over-complicate things unnecessarily.
I agree that it's weird to reuse max_dst_opts_cnt here:
1. The meaning is different from the Rx path.
2. We only enforce max_dst_opts_cnt, but not max_dst_opts_len.
3. The default is derived from the initial netns, unlike in the Rx path.
Given the above and that:
1. We believe that 8 options until the tunnel encapsulation limit option
is liberal enough.
2. We don't want to over-complicate things.
Can we go with an hard coded 8 and see if anyone complains? In the
unlikely case that someone complains we can at least gain some insight
into how this option is actually used with tunnels.
next prev parent reply other threads:[~2026-04-19 14:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-18 12:15 [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim Daniel Borkmann
2026-04-18 12:40 ` Justin Iurman
2026-04-18 22:19 ` Daniel Borkmann
2026-04-18 22:37 ` Justin Iurman
2026-04-19 14:31 ` Ido Schimmel [this message]
2026-04-20 18:55 ` Justin Iurman
2026-04-21 7:33 ` Daniel Borkmann
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=20260419143137.GA885197@shredder \
--to=idosch@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=justin.iurman@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tom@herbertland.com \
--cc=willemdebruijn.kernel@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