All of lore.kernel.org
 help / color / mirror / Atom feed
From: Parav Pandit <parav@nvidia.com>
To: Alexander H Duyck <alexander.duyck@gmail.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>
Cc: "edumazet@google.com" <edumazet@google.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>
Subject: RE: [PATCH net-next 1/2] virtio_net: Fix short frame length check
Date: Fri, 13 Jan 2023 23:37:56 +0000	[thread overview]
Message-ID: <PH0PR12MB5481C03EDED7C2D67395FCA4DCC29@PH0PR12MB5481.namprd12.prod.outlook.com> (raw)
In-Reply-To: <92b98f45dcd65facac78133c6250d9d96ea1a25f.camel@gmail.com>


> From: Alexander H Duyck <alexander.duyck@gmail.com>
> Sent: Friday, January 13, 2023 6:24 PM
> 
> On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without
> > any preemble and CRC.
> >
> > Current code only checks for minimal 14 bytes of Ethernet header length.
> > Correct it to consider the minimum Ethernet frame length.
> >
> > Fixes: 296f96fcfc16 ("Net driver using virtio")
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> > ---
> >  drivers/net/virtio_net.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > 7723b2a49d8e..d45e140b6852 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info *vi,
> struct receive_queue *rq,
> >  	struct sk_buff *skb;
> >  	struct virtio_net_hdr_mrg_rxbuf *hdr;
> >
> > -	if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> > +	if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> >  		pr_debug("%s: short packet %i\n", dev->name, len);
> >  		dev->stats.rx_length_errors++;
> >  		if (vi->mergeable_rx_bufs) {
> 
> I'm not sure I agree with this change as packets are only 60B if they have gone
> across the wire as they are usually padded out on the transmit side. There may
> be cases where software routed packets may not be 60B.
> 
Do you mean Linux kernel software? Any link to it would be helpful.

> As such rather than changing out ETH_HLEN for ETH_ZLEN I wonder if we
> should look at maybe making this a "<=" comparison instead since that is the
> only case I can think of where the packet would end up being entirely empty
> after eth_type_trans is called and we would be passing an skb with length 0.

I likely didn’t understand your comment.
This driver check is before creating the skb for the received packet.
So, purpose is to not even process the packet header or prepare the skb if it not an Ethernet frame.

It is interesting to know when we get < 60B frame.

WARNING: multiple messages have this Message-ID (diff)
From: Parav Pandit via Virtualization <virtualization@lists.linux-foundation.org>
To: Alexander H Duyck <alexander.duyck@gmail.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>
Cc: "edumazet@google.com" <edumazet@google.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: RE: [PATCH net-next 1/2] virtio_net: Fix short frame length check
Date: Fri, 13 Jan 2023 23:37:56 +0000	[thread overview]
Message-ID: <PH0PR12MB5481C03EDED7C2D67395FCA4DCC29@PH0PR12MB5481.namprd12.prod.outlook.com> (raw)
In-Reply-To: <92b98f45dcd65facac78133c6250d9d96ea1a25f.camel@gmail.com>


> From: Alexander H Duyck <alexander.duyck@gmail.com>
> Sent: Friday, January 13, 2023 6:24 PM
> 
> On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without
> > any preemble and CRC.
> >
> > Current code only checks for minimal 14 bytes of Ethernet header length.
> > Correct it to consider the minimum Ethernet frame length.
> >
> > Fixes: 296f96fcfc16 ("Net driver using virtio")
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> > ---
> >  drivers/net/virtio_net.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > 7723b2a49d8e..d45e140b6852 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info *vi,
> struct receive_queue *rq,
> >  	struct sk_buff *skb;
> >  	struct virtio_net_hdr_mrg_rxbuf *hdr;
> >
> > -	if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> > +	if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> >  		pr_debug("%s: short packet %i\n", dev->name, len);
> >  		dev->stats.rx_length_errors++;
> >  		if (vi->mergeable_rx_bufs) {
> 
> I'm not sure I agree with this change as packets are only 60B if they have gone
> across the wire as they are usually padded out on the transmit side. There may
> be cases where software routed packets may not be 60B.
> 
Do you mean Linux kernel software? Any link to it would be helpful.

> As such rather than changing out ETH_HLEN for ETH_ZLEN I wonder if we
> should look at maybe making this a "<=" comparison instead since that is the
> only case I can think of where the packet would end up being entirely empty
> after eth_type_trans is called and we would be passing an skb with length 0.

I likely didn’t understand your comment.
This driver check is before creating the skb for the received packet.
So, purpose is to not even process the packet header or prepare the skb if it not an Ethernet frame.

It is interesting to know when we get < 60B frame.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2023-01-13 23:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 22:36 [PATCH net-next 0/2] Small packet processing handling changes Parav Pandit
2023-01-13 22:36 ` Parav Pandit via Virtualization
2023-01-13 22:36 ` [PATCH net-next 1/2] virtio_net: Fix short frame length check Parav Pandit
2023-01-13 22:36   ` Parav Pandit via Virtualization
2023-01-13 23:24   ` Alexander H Duyck
2023-01-13 23:24     ` Alexander H Duyck
2023-01-13 23:37     ` Parav Pandit [this message]
2023-01-13 23:37       ` Parav Pandit via Virtualization
2023-01-14  0:23       ` Alexander Duyck
2023-01-14  0:23         ` Alexander Duyck
2023-01-14  0:36         ` Alexander Duyck
2023-01-14  0:36           ` Alexander Duyck
2023-01-14 17:44         ` Parav Pandit
2023-01-14 17:44           ` Parav Pandit via Virtualization
2023-01-13 22:36 ` [PATCH net-next 2/2] virtio_net: Reuse buffer free function Parav Pandit
2023-01-13 22:36   ` Parav Pandit via Virtualization
2023-01-13 23:25   ` Alexander H Duyck
2023-01-13 23:25     ` Alexander H Duyck
2023-01-16  2:28   ` Xuan Zhuo
2023-01-16  2:28     ` Xuan Zhuo
2023-01-14 17:46 ` [PATCH net-next 0/2] Small packet processing handling changes Parav Pandit
2023-01-14 17:46   ` Parav Pandit via Virtualization

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PH0PR12MB5481C03EDED7C2D67395FCA4DCC29@PH0PR12MB5481.namprd12.prod.outlook.com \
    --to=parav@nvidia.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.