Re: [PATCH net-next v4 4/5] net: hdlc_fr: Do skb_reset_mac_header for skbs received on normal PVC devices
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2020-10-30 22:22:53
Also in:
lkml
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2020-10-30 22:22:53
Also in:
lkml
On Fri, Oct 30, 2020 at 5:49 PM Xie He [off-list ref] wrote:
On Fri, Oct 30, 2020 at 2:28 PM Willem de Bruijn [off-list ref] wrote:quoted
Yes, it might require holding off the other patches until net is merged into net-next. Packet sockets are likely not the only way these packets are received? It changes mac_len as computed in __netif_receive_skb_core.I looked at __netif_receive_skb_core. I didn't see it computing mac_len?
It's indirect:
skb_reset_network_header(skb);
if (!skb_transport_header_was_set(skb))
skb_reset_transport_header(skb);
skb_reset_mac_len(skb);
I thought only AF_PACKET/RAW sockets would need this information because other upper layers would not care about what happened in L2.
I think that's a reasonable assumption. I don't have a good counterexample ready. Specific to this case, it seems to have been working with no one complaining so far ;)
I see mac_len is computed in netif_receive_generic_xdp. I'm not clear about the reason why it calculates it. But it seems that it considers the L2 header as an Ethernet header, which is incorrect for this driver.quoted
If there is no real bug that is fixed, net-next is fine.