Re: BUG_ON in skb_segment, after bpf_skb_change_proto was applied

[Shmulik Ladkani <shmulik.ladkani@gmail.com>]

On Mon, 26 Aug 2019 19:47:40 +0200
Eric Dumazet <eric.dumazet@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?

- 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.

Shmulik