Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim

[Justin Iurman <justin.iurman@gmail.com>]

On 4/19/26 16:31, Ido Schimmel wrote:
> 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.

In general, I'm not a big fan of hard-coded values, but I also think 
that in this context it would make sense to do so. This is not a strong 
+1, let's say it's more a "not against it".