[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iLQq9Uf+HJAAi30UO01SPR0q2jr6FKxmewz9v=8XjAwXA@mail.gmail.com>
Date: Thu, 26 Dec 2024 10:38:06 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Antonio Pastor <antonio.pastor@...il.com>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, horms@...nel.org,
kuba@...nel.org, "David S. Miller" <davem@...emloft.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v3] net: llc: reset skb->transport_header
On Wed, Dec 25, 2024 at 2:08 AM Antonio Pastor <antonio.pastor@...il.com> wrote:
>
> 802.2+LLC+SNAP frames received by napi_complete_done with GRO and DSA
> have skb->transport_header set two bytes short, or pointing 2 bytes
> before network_header & skb->data. As snap_rcv expects transport_header
> to point to SNAP header (OID:PID) after LLC processing advances offset
> over LLC header (llc_rcv & llc_fixup_skb), code doesn't find a match
> and packet is dropped.
>
> Between napi_complete_done and snap_rcv, transport_header is not used
> until __netif_receive_skb_core, where originally it was being reset.
> Commit fda55eca5a33 ("net: introduce skb_transport_header_was_set()")
> only does so if not set, on the assumption the value was set correctly
> by GRO (and also on assumption that "network stacks usually reset the
> transport header anyway"). Afterwards it is moved forward by
> llc_fixup_skb.
>
> Locally generated traffic shows up at __netif_receive_skb_core with no
> transport_header set and is processed without issue. On a setup with
> GRO but no DSA, transport_header and network_header are both set to
> point to skb->data which is also correct.
>
> As issue is LLC specific, to avoid impacting non-LLC traffic, and to
> follow up on original assumption made on previous code change,
> llc_fixup_skb to reset the offset after skb pull. llc_fixup_skb
> assumes the LLC header is at skb->data, and by definition SNAP header
> immediately follows.
>
> Fixes: fda55eca5a33 ("net: introduce skb_transport_header_was_set()")
> Signed-off-by: Antonio Pastor <antonio.pastor@...il.com>
Reviewed-by: Eric Dumazet <edumazet@...gle.com>
Powered by blists - more mailing lists