Re: Expose skb_gso_validate_network_len() [Was: ebtables: load-on-demand extensions]

[Eugene Crosser <crosser@average.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --]

On 22/06/2020 06:50, Jan Engelhardt wrote:

>> What short-circuit behaviour?
>>
>> The difference we're talking about is:
>> *reg = get_gso_segment_or_nh_len(skb);
>> vs.
>> if (!skb_is_gso(skb) || get_gso_segment_len(skb) <= priv->len))
>>       regs->verdict.code = NFT_BREAK;
> 
> I was under the impression the discussion had steered on
> 
>   *reg1 = skb_gso_size_check(skb, skb_gso_validate_network_len(skb, priv->len));
>   verdict = *reg1 ? NFT_CONTINUE : NFT_BREAK;
> 
> vs.
> 
>   *reg1 = 0;
>   skb_walk_frags(skb, iter)
>       *reg1 += seg_len + skb_headlen(iter);
>   // and leave reg1 for the next nft op (lt/gt/feeding it to a counter/etc.)

skb_gso_size_check() has skb_walk_frags() inside. This internal skb_walk_frags()
terminates early (is "short-cirquited"?) when a non-compliant segment is
encountered.

If we want to expose the _maximum length_ of the segments, we need another
function that _also_ performs skb_walk_frags() and runs it to the end (does not
"short-circuit").

Performance-wise, this is probably not a significant penalty in most cases. But
it does require a new function that finds the maximum segment length.

Regards,

Eugene


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]