Tue, Nov 20, 2018 at 12:39:56PM CET, [email protected] wrote: >When a packet is trapped and the corresponding SKB marked as >already-forwarded, it retains this marking even after it is forwarded >across veth links into another bridge. There, since it ingresses the >bridge over veth, which doesn't have offload_fwd_mark, it triggers a >warning in nbp_switchdev_frame_mark(). > >Then nbp_switchdev_allowed_egress() decides not to allow egress from >this bridge through another veth, because the SKB is already marked, and >the mark (of 0) of course matches. Thus the packet is incorrectly >blocked. > >Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That >function is called from tunnels and also from veth, and thus catches the >cases where traffic is forwarded between bridges and transformed in a >way that invalidates the marking. > >Fixes: 6bc506b4fb06 ("bridge: switchdev: Add forward mark support for stacked >devices") >Fixes: abf4bb6b63d0 ("skbuff: Add the offload_mr_fwd_mark field") >Signed-off-by: Petr Machata <[email protected]> >Suggested-by: Ido Schimmel <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
