* [net,v2] net/packet: fix packet receive on L3 devices without visible hard header
@ 2020-11-21 6:28 Eyal Birger
2020-11-21 7:51 ` Jason A. Donenfeld
2020-12-24 10:06 ` Xie He
0 siblings, 2 replies; 5+ messages in thread
From: Eyal Birger @ 2020-11-21 6:28 UTC (permalink / raw)
To: willemdebruijn.kernel, davem, kuba
Cc: Jason, netdev, xie.he.0141, Eyal Birger
In the patchset merged by commit b9fcf0a0d826
("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which
did not have header_ops were given one for the purpose of protocol parsing
on af_packet transmit path.
That change made af_packet receive path regard these devices as having a
visible L3 header and therefore aligned incoming skb->data to point to the
skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not
reset their mac_header prior to ingress and therefore their incoming
packets became malformed.
Ideally these devices would reset their mac headers, or af_packet would be
able to rely on dev->hard_header_len being 0 for such cases, but it seems
this is not the case.
Fix by changing af_packet RX ll visibility criteria to include the
existence of a '.create()' header operation, which is used when creating
a device hard header - via dev_hard_header() - by upper layers, and does
not exist in these L3 devices.
As this predicate may be useful in other situations, add it as a common
dev_has_header() helper in netdevice.h.
Fixes: b9fcf0a0d826 ("Merge branch 'support-AF_PACKET-for-layer-3-devices'")
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
---
v2:
- add common dev_has_header() helper as suggested by Willem de Bruijn
---
include/linux/netdevice.h | 5 +++++
net/packet/af_packet.c | 18 +++++++++---------
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 964b494b0e8d..fa275a054f46 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3137,6 +3137,11 @@ static inline bool dev_validate_header(const struct net_device *dev,
return false;
}
+static inline bool dev_has_header(const struct net_device *dev)
+{
+ return dev->header_ops && dev->header_ops->create;
+}
+
typedef int gifconf_func_t(struct net_device * dev, char __user * bufptr,
int len, int size);
int register_gifconf(unsigned int family, gifconf_func_t *gifconf);
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index cefbd50c1090..7a18ffff8551 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -93,8 +93,8 @@
/*
Assumptions:
- - If the device has no dev->header_ops, there is no LL header visible
- above the device. In this case, its hard_header_len should be 0.
+ - If the device has no dev->header_ops->create, there is no LL header
+ visible above the device. In this case, its hard_header_len should be 0.
The device may prepend its own header internally. In this case, its
needed_headroom should be set to the space needed for it to add its
internal header.
@@ -108,26 +108,26 @@
On receive:
-----------
-Incoming, dev->header_ops != NULL
+Incoming, dev_has_header(dev) == true
mac_header -> ll header
data -> data
-Outgoing, dev->header_ops != NULL
+Outgoing, dev_has_header(dev) == true
mac_header -> ll header
data -> ll header
-Incoming, dev->header_ops == NULL
+Incoming, dev_has_header(dev) == false
mac_header -> data
However drivers often make it point to the ll header.
This is incorrect because the ll header should be invisible to us.
data -> data
-Outgoing, dev->header_ops == NULL
+Outgoing, dev_has_header(dev) == false
mac_header -> data. ll header is invisible to us.
data -> data
Resume
- If dev->header_ops == NULL we are unable to restore the ll header,
+ If dev_has_header(dev) == false we are unable to restore the ll header,
because it is invisible to us.
@@ -2069,7 +2069,7 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
skb->dev = dev;
- if (dev->header_ops) {
+ if (dev_has_header(dev)) {
/* The device has an explicit notion of ll header,
* exported to higher levels.
*
@@ -2198,7 +2198,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
if (!net_eq(dev_net(dev), sock_net(sk)))
goto drop;
- if (dev->header_ops) {
+ if (dev_has_header(dev)) {
if (sk->sk_type != SOCK_DGRAM)
skb_push(skb, skb->data - skb_mac_header(skb));
else if (skb->pkt_type == PACKET_OUTGOING) {
--
2.25.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [net,v2] net/packet: fix packet receive on L3 devices without visible hard header
2020-11-21 6:28 [net,v2] net/packet: fix packet receive on L3 devices without visible hard header Eyal Birger
@ 2020-11-21 7:51 ` Jason A. Donenfeld
2020-11-21 13:23 ` Willem de Bruijn
2020-12-24 10:06 ` Xie He
1 sibling, 1 reply; 5+ messages in thread
From: Jason A. Donenfeld @ 2020-11-21 7:51 UTC (permalink / raw)
To: Eyal Birger; +Cc: willemdebruijn.kernel, davem, kuba, netdev, xie.he.0141
On 11/21/20, Eyal Birger <eyal.birger@gmail.com> wrote:
> In the patchset merged by commit b9fcf0a0d826
> ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which
> did not have header_ops were given one for the purpose of protocol parsing
> on af_packet transmit path.
>
> That change made af_packet receive path regard these devices as having a
> visible L3 header and therefore aligned incoming skb->data to point to the
> skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not
> reset their mac_header prior to ingress and therefore their incoming
> packets became malformed.
>
> Ideally these devices would reset their mac headers, or af_packet would be
> able to rely on dev->hard_header_len being 0 for such cases, but it seems
> this is not the case.
>
> Fix by changing af_packet RX ll visibility criteria to include the
> existence of a '.create()' header operation, which is used when creating
> a device hard header - via dev_hard_header() - by upper layers, and does
> not exist in these L3 devices.
>
> As this predicate may be useful in other situations, add it as a common
> dev_has_header() helper in netdevice.h.
>
> Fixes: b9fcf0a0d826 ("Merge branch
> 'support-AF_PACKET-for-layer-3-devices'")
> Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
>
> ---
>
> v2:
> - add common dev_has_header() helper as suggested by Willem de Bruijn
> ---
> include/linux/netdevice.h | 5 +++++
> net/packet/af_packet.c | 18 +++++++++---------
> 2 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 964b494b0e8d..fa275a054f46 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -3137,6 +3137,11 @@ static inline bool dev_validate_header(const struct
> net_device *dev,
> return false;
> }
>
> +static inline bool dev_has_header(const struct net_device *dev)
> +{
> + return dev->header_ops && dev->header_ops->create;
> +}
> +
> typedef int gifconf_func_t(struct net_device * dev, char __user * bufptr,
> int len, int size);
> int register_gifconf(unsigned int family, gifconf_func_t *gifconf);
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index cefbd50c1090..7a18ffff8551 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -93,8 +93,8 @@
>
> /*
> Assumptions:
> - - If the device has no dev->header_ops, there is no LL header visible
> - above the device. In this case, its hard_header_len should be 0.
> + - If the device has no dev->header_ops->create, there is no LL header
> + visible above the device. In this case, its hard_header_len should be
> 0.
> The device may prepend its own header internally. In this case, its
> needed_headroom should be set to the space needed for it to add its
> internal header.
> @@ -108,26 +108,26 @@
> On receive:
> -----------
>
> -Incoming, dev->header_ops != NULL
> +Incoming, dev_has_header(dev) == true
> mac_header -> ll header
> data -> data
>
> -Outgoing, dev->header_ops != NULL
> +Outgoing, dev_has_header(dev) == true
> mac_header -> ll header
> data -> ll header
>
> -Incoming, dev->header_ops == NULL
> +Incoming, dev_has_header(dev) == false
> mac_header -> data
> However drivers often make it point to the ll header.
> This is incorrect because the ll header should be invisible to us.
> data -> data
>
> -Outgoing, dev->header_ops == NULL
> +Outgoing, dev_has_header(dev) == false
> mac_header -> data. ll header is invisible to us.
> data -> data
>
> Resume
> - If dev->header_ops == NULL we are unable to restore the ll header,
> + If dev_has_header(dev) == false we are unable to restore the ll header,
> because it is invisible to us.
>
>
> @@ -2069,7 +2069,7 @@ static int packet_rcv(struct sk_buff *skb, struct
> net_device *dev,
>
> skb->dev = dev;
>
> - if (dev->header_ops) {
> + if (dev_has_header(dev)) {
> /* The device has an explicit notion of ll header,
> * exported to higher levels.
> *
> @@ -2198,7 +2198,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct
> net_device *dev,
> if (!net_eq(dev_net(dev), sock_net(sk)))
> goto drop;
>
> - if (dev->header_ops) {
> + if (dev_has_header(dev)) {
> if (sk->sk_type != SOCK_DGRAM)
> skb_push(skb, skb->data - skb_mac_header(skb));
> else if (skb->pkt_type == PACKET_OUTGOING) {
Thanks for fixing this. Patch seems correct to me.
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [net,v2] net/packet: fix packet receive on L3 devices without visible hard header
2020-11-21 7:51 ` Jason A. Donenfeld
@ 2020-11-21 13:23 ` Willem de Bruijn
2020-11-24 2:58 ` Jakub Kicinski
0 siblings, 1 reply; 5+ messages in thread
From: Willem de Bruijn @ 2020-11-21 13:23 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Eyal Birger, Willem de Bruijn, David Miller, Jakub Kicinski,
Network Development, Xie He
On Sat, Nov 21, 2020 at 2:56 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On 11/21/20, Eyal Birger <eyal.birger@gmail.com> wrote:
> > In the patchset merged by commit b9fcf0a0d826
> > ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which
> > did not have header_ops were given one for the purpose of protocol parsing
> > on af_packet transmit path.
> >
> > That change made af_packet receive path regard these devices as having a
> > visible L3 header and therefore aligned incoming skb->data to point to the
> > skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not
> > reset their mac_header prior to ingress and therefore their incoming
> > packets became malformed.
> >
> > Ideally these devices would reset their mac headers, or af_packet would be
> > able to rely on dev->hard_header_len being 0 for such cases, but it seems
> > this is not the case.
> >
> > Fix by changing af_packet RX ll visibility criteria to include the
> > existence of a '.create()' header operation, which is used when creating
> > a device hard header - via dev_hard_header() - by upper layers, and does
> > not exist in these L3 devices.
> >
> > As this predicate may be useful in other situations, add it as a common
> > dev_has_header() helper in netdevice.h.
> >
> > Fixes: b9fcf0a0d826 ("Merge branch
> > 'support-AF_PACKET-for-layer-3-devices'")
> > Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [net,v2] net/packet: fix packet receive on L3 devices without visible hard header
2020-11-21 13:23 ` Willem de Bruijn
@ 2020-11-24 2:58 ` Jakub Kicinski
0 siblings, 0 replies; 5+ messages in thread
From: Jakub Kicinski @ 2020-11-24 2:58 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Jason A. Donenfeld, Eyal Birger, David Miller,
Network Development, Xie He
On Sat, 21 Nov 2020 08:23:30 -0500 Willem de Bruijn wrote:
> On Sat, Nov 21, 2020 at 2:56 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > On 11/21/20, Eyal Birger <eyal.birger@gmail.com> wrote:
> > > In the patchset merged by commit b9fcf0a0d826
> > > ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which
> > > did not have header_ops were given one for the purpose of protocol parsing
> > > on af_packet transmit path.
> > >
> > > That change made af_packet receive path regard these devices as having a
> > > visible L3 header and therefore aligned incoming skb->data to point to the
> > > skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not
> > > reset their mac_header prior to ingress and therefore their incoming
> > > packets became malformed.
> > >
> > > Ideally these devices would reset their mac headers, or af_packet would be
> > > able to rely on dev->hard_header_len being 0 for such cases, but it seems
> > > this is not the case.
> > >
> > > Fix by changing af_packet RX ll visibility criteria to include the
> > > existence of a '.create()' header operation, which is used when creating
> > > a device hard header - via dev_hard_header() - by upper layers, and does
> > > not exist in these L3 devices.
> > >
> > > As this predicate may be useful in other situations, add it as a common
> > > dev_has_header() helper in netdevice.h.
> > >
> > > Fixes: b9fcf0a0d826 ("Merge branch
> > > 'support-AF_PACKET-for-layer-3-devices'")
> > > Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
>
> > Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
>
> Acked-by: Willem de Bruijn <willemb@google.com>
Applied, thanks!
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [net,v2] net/packet: fix packet receive on L3 devices without visible hard header
2020-11-21 6:28 [net,v2] net/packet: fix packet receive on L3 devices without visible hard header Eyal Birger
2020-11-21 7:51 ` Jason A. Donenfeld
@ 2020-12-24 10:06 ` Xie He
1 sibling, 0 replies; 5+ messages in thread
From: Xie He @ 2020-12-24 10:06 UTC (permalink / raw)
To: Eyal Birger
Cc: Willem de Bruijn, David S. Miller, Jakub Kicinski, Jason,
Linux Kernel Network Developers
On Fri, Nov 20, 2020 at 10:28 PM Eyal Birger <eyal.birger@gmail.com> wrote:
>
> Fix by changing af_packet RX ll visibility criteria to include the
> existence of a '.create()' header operation, which is used when creating
> a device hard header - via dev_hard_header() - by upper layers, and does
> not exist in these L3 devices.
This patch changed the RX LL visibility criteria (in the comment) to
"dev_has_header". We need to change the TX LL visibility criteria (in
the same comment), too.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-12-24 10:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-21 6:28 [net,v2] net/packet: fix packet receive on L3 devices without visible hard header Eyal Birger
2020-11-21 7:51 ` Jason A. Donenfeld
2020-11-21 13:23 ` Willem de Bruijn
2020-11-24 2:58 ` Jakub Kicinski
2020-12-24 10:06 ` Xie He
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).