8e69ec111f
If a tc ebpf program writes into a packet using direct packet access then the packet will automatically be uncloned and pulled by additional prologue inserted by the kernel itself. See tc_cls_act_prologue() & bpf_unclone_prologue() in kernel sources (this is how the clat ebpf program works, which does DPA writes). However in the forwarding programs we only *read* from the packets using direct packet access, but never write. All writes happen via kernel bpf helpers (this is mostly an implementation detail: since we need to use helpers for checksum updates, I decided to also use checksums for the writes themselves). As such the insert 'automatic unclone/pull' logic doesn't trigger. It is thus possible (it depends on the skb layout delivered by the nic driver) for 0 bytes of the packet to be accessible for read using direct packet access. We thus need to explicitly try to pull in the header of the packet so that we can inspect it. In most cases (on most drivers for most packet types) this will end up being a no-op (because the headers will already be in the linear portion of the skb). But on some drivers for some packet types it ends up mattering. Test: TreeHugger, makes icmpv6 tether forwarding work on bramble Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: I4b07e57728ce544ffb908527ea11ecc315e5acec