Re: [PATCH] [RFC] net: bpf: make __bpf_skb_max_len(skb) an skb-independent constant

[Maciej Åenczykowski]

This is only a semi serious patch.

But, I've spent a long time trying to come up with a solution that works,
and everything seems broken.

I'm hoping someone else has some ideas.

As is, forwarding doesn't work.

Here's an example scenario:

cell0 - 1500 l3 mtu, raw_ip, 0 l2 header
wlan0 - 1500 l3 mtu, ethernet, 14 l2 header

cell0 -> wlan0 forwarding

tc ingress hook on cell0:
  map lookups, other stuff, eventually
  skb_modifications to add ethernet header (via skb_change_head or
bpf_skb_adjust_room)
  bpf_redirect(wlan0, egress)

This fails because adding ethernet header goes above the cell0 ->
mtu+header_len,
even though it would be fine if we tested against wlan0 -> mtu+header_len

Indeed the only solution that would perhaps work is to have 2 bpf programs

tc ingress hook on cell0: redirect to wlan0
tc egress hook on wlan0: actually add the header

but this requires doing the lookups twice - first to determine if
should redirect and where,
and then to actually add the header.  additionally the packet we get
on wlan0 might
not have come from the redirect... and that's hard to detect...

so you actually need to do:

tc ingress hook on cell0: redirect to dummy0, which has larger mtu
tc ingress hook on dummy0: add header, redirect to wlan0

this still requires a double set of bpf programs and lookups...
it's ugly.

Calling bpf_redirect() prior to skb_change_head() isn't enough, since it checks
skb->dev not tgt_index.  Although I guess we could save the redirect device's
mtu in the redirect struct and test against that in preference to
testing against skb->dev...
but that's really a pointless test, because you can call bpf_redirect
multiple times
changing the device, ie...

bpf_redirect(dummy with large mtu)
skb_change_head()
bpf_redirect(wlan0)

so basically this would make the test worthless...

I considered simply removing the mtu check from these skb modifying functions...
it's not like it even does the right thing:
(a) device mtu is only an upper limit - we should really be testing
against path mtu
      and that's probably only something the bpf code knows
(b) it ignores mtu entirely for gso packets: but gso max seg size
should be tested instead...

Or maybe add a bpf uapi visible flag to ignore the mtu check...

Or maybe simply pass in 16-bits of mtu via the currently unused flags field...

... etc ...

- Maciej