| Message ID | 160208776033.798237.4028465222836713720.stgit@firesoul |
|---|---|
| State | Superseded |
| Headers | show |
| Series | bpf: New approach for BPF MTU handling and enforcement | expand |
On 10/7/20 6:22 PM, Jesper Dangaard Brouer wrote: [...] > > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> > (imported from commit 37f8552786cf46588af52b77829b730dd14524d3) slipped in?
> static u32 __bpf_skb_max_len(const struct sk_buff *skb) > { > - return skb->dev ? skb->dev->mtu + skb->dev->hard_header_len : > - SKB_MAX_ALLOC; > + return IP_MAX_MTU; > } Shouldn't we just delete this helper instead and replace call sites?
diff --git a/net/core/filter.c b/net/core/filter.c index 05df73780dd3..fed239e77bdc 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -3476,8 +3476,7 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 off, u32 len_diff, static u32 __bpf_skb_max_len(const struct sk_buff *skb) { - return skb->dev ? skb->dev->mtu + skb->dev->hard_header_len : - SKB_MAX_ALLOC; + return IP_MAX_MTU; } BPF_CALL_4(sk_skb_adjust_room, struct sk_buff *, skb, s32, len_diff,
Multiple BPF-helpers that can manipulate/increase the size of the SKB uses __bpf_skb_max_len() as the max-length. This function limit size against the current net_device MTU (skb->dev->mtu). When a BPF-prog grow the packet size, then it should not be limited to the MTU. The MTU is a transmit limitation, and software receiving this packet should be allowed to increase the size. Further more, current MTU check in __bpf_skb_max_len uses the MTU from ingress/current net_device, which in case of redirects uses the wrong net_device. Keep a sanity max limit of IP_MAX_MTU which is 64KiB. In later patches we will enforce the MTU limitation when transmitting packets. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> (imported from commit 37f8552786cf46588af52b77829b730dd14524d3) --- net/core/filter.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)