On 09/28, Jakub Kicinski wrote: > skb BPF paths have a number of helpers to fix up the GSO > state after packet modifications. XDP has no such support. > > "Real" / driver XDP runs before the SW GRO, and drivers generally > disable HW-GRO when XDP is attached (with the exception of IDPF, > story for another time), so this is not an issue. We also try > to disable HW-GRO and elide SW GRO when generic XDP prog is > attached. These precautions are not 100% today, and IMHO fixing > that is impossible. Let's explicitly drop GSO skbs on input to XDP. > > First example how things can go sideways today - bonding. > We only disable & elide GRO on the device to which program is > attached. Nothing reaches the devices below it, and for a stacked > device that is where the packets come from: > > ip link set dev bond0 xdpgeneric obj prog.o sec xdp > > leaves every slave with GRO on and no xdp_prog of its own, so > netif_elide_gro() lets them coalesce as usual. bond_handle_frame() > then returns RX_HANDLER_ANOTHER, __netif_receive_skb_core() loops back > round to another_round with skb->dev switched to the bond, and the > program gets handed a packet which was never on the wire. HW-GRO is > the same story - while netif_disable_lro() walks the lower devices, > its HW-GRO counterpart never did (this is largely the point of > distinguishing between LRO and HW-GRO). > > Example two - veth. Generic XDP on a veth gets there by a different route. > veth_xdp_set() takes NETIF_F_GSO_SOFTWARE away from the peer so that > no GSO skb is ever built for a device running XDP, but generic XDP does > not go through ndo_bpf, so none of that happens. > > Signed-off-by: Jakub Kicinski <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
