On 8/27/19 1:42 PM, Shmulik Ladkani wrote:
> On Mon, 26 Aug 2019 19:47:40 +0200
> Eric Dumazet <eric.duma...@gmail.com> wrote:
>
>> On 8/26/19 4:07 PM, Shmulik Ladkani wrote:
>>> - ipv4 forwarding to dummy1, where eBPF nat4-to-6 program is attached
>>> at TC Egress (calls 'bpf_skb_change_proto()'), then redirect to ingress
>>> on same device.
>>> NOTE: 'bpf_skb_proto_4_to_6()' mangles 'shinfo->gso_size'
>>
>> Doing this on an skb with a frag_list is doomed, in current gso_segment()
>> state.
>>
>> A rewrite would be needed (I believe I did so at some point, but Herbert Xu
>> fought hard against it)
>
> Thanks Eric,
>
> - If a rewrite is still considered out of the question, how can one use
> eBPF's bpf_skb_change_proto() safely without disabling GRO completely?
> - e.g. is there a way to force the GROed skbs to fit into a layout that is
> tolerated by skb_segment?
> - alternatively can eBPF layer somehow enforce segmentation of the
> original GROed skb before mangling the gso_size?
>
> - Another thing that puzzles me is that we hit the BUG_ON rather rarely
> and cannot yet reproduce synthetically. If skb_segment's handling of
> skbs with a frag_list (that have gso_size mangled) is broken, I'd expect
> to hit this more often... Any ideas?
skb_segment of a gro packet (especially with frag_list) is only supported
if the geometry of the individual segments is not changed,
meaning that gso_size must remain the same.
>
> - Suppose going for a rewrite, care to elaborate what's exactly missing
> in skb_segment's logic?
> I must admit I do not fully understand all the different code flows in
> this function, it seems to support many different input skbs - any
> assistance is highly appreciated.
Well, this is the point really.
The complexity of this function is so high that very few of us dare to touch it.
