All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [Patch net] igb: pass the correct maxlen for eth_get_headlen()
Date: Thu, 23 Apr 2015 12:45:21 -0700	[thread overview]
Message-ID: <55394BD1.5040006@redhat.com> (raw)
In-Reply-To: <CAHA+R7OhbCSjggyb_Deq_jmoDWzEcR+=hhkKjyE9Pue7bXOmHg@mail.gmail.com>

On 04/23/2015 12:30 PM, Cong Wang wrote:
> (Off-topic...)
>
> On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang <cwang@twopensource.com> wrote:
>> The code looks correct to me now, except it is suspicious skb->len
>> is not updated after skb_copy_to_linear_data() while skb->tail is
>> advanced already. I need to think more before submitting a patch.
> I feel like we need the following patch, maybe skb->len is updated somewhere
> else by "skb->tail - skb->head", otherwise we are screwed?

Maybe in skb_add_rx_frag?  You might take a look at it.

>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index a0a9b1f..66e6fb6 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -6843,7 +6843,6 @@ static void igb_pull_tail(struct igb_ring *rx_ring,
>                  skb_frag_size_sub(frag, IGB_TS_HDR_LEN);
>                  frag->page_offset += IGB_TS_HDR_LEN;
>                  skb->data_len -= IGB_TS_HDR_LEN;
> -               skb->len -= IGB_TS_HDR_LEN;
>
>                  /* move va to start of packet data */
>                  va += IGB_TS_HDR_LEN;
> @@ -6856,12 +6855,12 @@ static void igb_pull_tail(struct igb_ring *rx_ring,
>
>          /* align pull length to size of long to optimize memcpy performance */
>          skb_copy_to_linear_data(skb, va, ALIGN(pull_len, sizeof(long)));
> +       __skb_put(skb, pull_len);
>
>          /* update all of the pointers */
>          skb_frag_size_sub(frag, pull_len);
>          frag->page_offset += pull_len;
>          skb->data_len -= pull_len;
> -       skb->tail += pull_len;
>   }
>
>   /**

Seriously?  Are you even reading the code?  The fragment is already a 
part of the skb, as such it is already included in skb->len. By 
re-adding the header you are adding bytes that aren't there.  All we 
were doing is moving data from a fragment to the linear portion.

No offense but your starting to waste my time with these silly patch 
ideas.  The patches I submitted to intel-wired-lan fix the issue that 
you found, and there aren't any new issues that it creates so the issue 
is resolved.  And like I said if you need to fix this in stable just 
subtract IGB_TS_HDR_LEN from the header length scanned in 
eth_get_headlen and it will resolve the issue you reported and that way 
we can fix the issue and avoid pulling a fragment down to size 0.

- Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Cong Wang <cwang@twopensource.com>,
	Alexander Duyck <alexander.duyck@gmail.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
	intel-wired-lan@lists.osuosl.org, netdev <netdev@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [Patch net] igb: pass the correct maxlen for eth_get_headlen()
Date: Thu, 23 Apr 2015 12:45:21 -0700	[thread overview]
Message-ID: <55394BD1.5040006@redhat.com> (raw)
In-Reply-To: <CAHA+R7OhbCSjggyb_Deq_jmoDWzEcR+=hhkKjyE9Pue7bXOmHg@mail.gmail.com>

On 04/23/2015 12:30 PM, Cong Wang wrote:
> (Off-topic...)
>
> On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang <cwang@twopensource.com> wrote:
>> The code looks correct to me now, except it is suspicious skb->len
>> is not updated after skb_copy_to_linear_data() while skb->tail is
>> advanced already. I need to think more before submitting a patch.
> I feel like we need the following patch, maybe skb->len is updated somewhere
> else by "skb->tail - skb->head", otherwise we are screwed?

Maybe in skb_add_rx_frag?  You might take a look at it.

>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index a0a9b1f..66e6fb6 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -6843,7 +6843,6 @@ static void igb_pull_tail(struct igb_ring *rx_ring,
>                  skb_frag_size_sub(frag, IGB_TS_HDR_LEN);
>                  frag->page_offset += IGB_TS_HDR_LEN;
>                  skb->data_len -= IGB_TS_HDR_LEN;
> -               skb->len -= IGB_TS_HDR_LEN;
>
>                  /* move va to start of packet data */
>                  va += IGB_TS_HDR_LEN;
> @@ -6856,12 +6855,12 @@ static void igb_pull_tail(struct igb_ring *rx_ring,
>
>          /* align pull length to size of long to optimize memcpy performance */
>          skb_copy_to_linear_data(skb, va, ALIGN(pull_len, sizeof(long)));
> +       __skb_put(skb, pull_len);
>
>          /* update all of the pointers */
>          skb_frag_size_sub(frag, pull_len);
>          frag->page_offset += pull_len;
>          skb->data_len -= pull_len;
> -       skb->tail += pull_len;
>   }
>
>   /**

Seriously?  Are you even reading the code?  The fragment is already a 
part of the skb, as such it is already included in skb->len. By 
re-adding the header you are adding bytes that aren't there.  All we 
were doing is moving data from a fragment to the linear portion.

No offense but your starting to waste my time with these silly patch 
ideas.  The patches I submitted to intel-wired-lan fix the issue that 
you found, and there aren't any new issues that it creates so the issue 
is resolved.  And like I said if you need to fix this in stable just 
subtract IGB_TS_HDR_LEN from the header length scanned in 
eth_get_headlen and it will resolve the issue you reported and that way 
we can fix the issue and avoid pulling a fragment down to size 0.

- Alex

  reply	other threads:[~2015-04-23 19:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-22 17:45 [Intel-wired-lan] [Patch net] igb: pass the correct maxlen for eth_get_headlen() Cong Wang
2015-04-22 17:45 ` Cong Wang
2015-04-22 17:45 ` [Intel-wired-lan] [Patch net] fm10k: " Cong Wang
2015-04-22 17:45   ` Cong Wang
2015-04-22 17:45 ` [Intel-wired-lan] [Patch net] ixgbe: " Cong Wang
2015-04-22 17:45   ` Cong Wang
2015-04-22 17:46 ` [Intel-wired-lan] [Patch net] ixgbevf: " Cong Wang
2015-04-22 17:46   ` Cong Wang
2015-04-22 19:43 ` [Intel-wired-lan] [Patch net] igb: " Alexander Duyck
2015-04-22 19:43   ` Alexander Duyck
2015-04-22 20:14   ` [Intel-wired-lan] " Cong Wang
2015-04-22 20:14     ` Cong Wang
2015-04-22 20:21     ` [Intel-wired-lan] " Alexander Duyck
2015-04-22 20:21       ` Alexander Duyck
2015-04-22 20:33       ` [Intel-wired-lan] " Cong Wang
2015-04-22 20:33         ` Cong Wang
2015-04-22 21:42         ` [Intel-wired-lan] " Alexander Duyck
2015-04-22 21:42           ` Alexander Duyck
2015-04-22 21:56           ` [Intel-wired-lan] " Cong Wang
2015-04-22 21:56             ` Cong Wang
2015-04-22 22:34             ` [Intel-wired-lan] " Alexander Duyck
2015-04-22 22:34               ` Alexander Duyck
2015-04-22 23:23               ` [Intel-wired-lan] " Cong Wang
2015-04-22 23:23                 ` Cong Wang
2015-04-23  3:40                 ` [Intel-wired-lan] " Alexander Duyck
2015-04-23  3:40                   ` Alexander Duyck
2015-04-23 18:06                   ` [Intel-wired-lan] " Cong Wang
2015-04-23 18:06                     ` Cong Wang
2015-04-23 18:40                     ` [Intel-wired-lan] " Alexander Duyck
2015-04-23 18:40                       ` Alexander Duyck
2015-04-23 19:14                       ` [Intel-wired-lan] " Cong Wang
2015-04-23 19:14                         ` Cong Wang
2015-04-23 19:30                 ` [Intel-wired-lan] " Cong Wang
2015-04-23 19:30                   ` Cong Wang
2015-04-23 19:45                   ` Alexander Duyck [this message]
2015-04-23 19:45                     ` [Intel-wired-lan] " Alexander Duyck
2015-04-23 22:07                     ` Cong Wang
2015-04-23 22:07                       ` Cong Wang
2015-04-25  1:07 ` Jeff Kirsher
2015-04-25  1:07   ` Jeff Kirsher

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=55394BD1.5040006@redhat.com \
    --to=alexander.h.duyck@redhat.com \
    --cc=intel-wired-lan@osuosl.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.