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
next prev parent 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.