Messages in this thread | | | From | Maciej Żenczykowski <> | Date | Mon, 20 Apr 2020 16:26:58 -0700 | Subject | Re: [PATCH] [RFC] net: bpf: make __bpf_skb_max_len(skb) an skb-independent constant |
| |
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
| |