From: Weilong Chen <chenweilong@huawei.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>,
<alexander.h.duyck@redhat.com>, <willemb@google.com>,
<hannes@stressinduktion.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] net: Check frag_lists first to prevent data out of order
Date: Fri, 28 Aug 2015 13:33:14 +0800 [thread overview]
Message-ID: <55DFF29A.1090208@huawei.com> (raw)
In-Reply-To: <1440736631.8932.43.camel@edumazet-glaptop2.roam.corp.google.com>
在 2015/8/28 12:37, Eric Dumazet 写道:
> On Fri, 2015-08-28 at 11:35 +0800, Weilong Chen wrote:
>> Thanks for reply.
>>
>>> On Wed, 2015-08-26 at 19:12 -0700, Eric Dumazet wrote:
>>>> On Thu, 2015-08-27 at 08:56 +0800, chenweilong@huawei.com wrote:
>>>>> From: Weilong Chen <chenweilong@huawei.com>
>>>>>
>>>>> When try to merge several skbs to prior one, if the frag_list is
>>>>> used and the the last one is a small packet, once the condition
>>>>> "len <= skb_tailroom(to)" is satisfied, we will get a wrong
>>>>> packet!
>>>>> This patch just check frag_lists before the condtion to prevent
>>>>> this from happening.
>>>>>
>>>>> Signed-off-by: Weilong Chen <chenweilong@huawei.com>
>>>>> ---
>>>>> net/core/skbuff.c | 6 +++---
>>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>>>>> index 8a725cc..d08edcb 100644
>>>>> --- a/net/core/skbuff.c
>>>>> +++ b/net/core/skbuff.c
>>>>> @@ -4133,6 +4133,9 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
>>>>> if (skb_cloned(to))
>>>>> return false;
>>>>>
>>>>> + if (skb_has_frag_list(to) || skb_has_frag_list(from))
>>>>> + return false;
>>>>> +
>>>>> if (len <= skb_tailroom(to)) {
>>>>> if (len)
>>>>> BUG_ON(skb_copy_bits(from, 0, skb_put(to, len), len));
>>>>> @@ -4140,9 +4143,6 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
>>>>> return true;
>>>>> }
>>>>>
>>>>> - if (skb_has_frag_list(to) || skb_has_frag_list(from))
>>>>> - return false;
>>>>> -
>>>>> if (skb_headlen(from) != 0) {
>>>>> struct page *page;
>>>>> unsigned int offset;
>>>>
>>>> Sigh.
>>>>
>>>> No idea what problem you tried to solve.
>>>>
>>>> This patch is not needed.
>>>>
>>>> If (len <= skb_tailroom()), then it is obviously correct to copy_bits()
>>>> the bytes.
>>>>
>>>> Hints :
>>>>
>>>> - If @to has a fraglist, then skb_tailroom(to) is 0 so the copy can not
>>>> be done.
>>
>> How to make sure it?
>> In my test, @to has a fraglist, but skb_tailroom(to) is not 0!
>> The test is about tipc, the function tipc_buf_append will merge 3 skbs
>> to one:
>> packet 1: len = 1420 skb_tailroom = 190
>> packet 2: len = 1420
>> packet 2 will be add to 1' fraglist, but not update skb_tailroom
>> packet 3: len = 60
>> Here's the error!
>
> Then fix tipc, or make sure you read and understood the code.
>
> By definition, if one skb has something in fraglist, it is non linear.
>
> If you read skb_tailroom(), you'll see this function returns 0 if skb is
> non linear.
Yes you'er right, when packet 2 is add to 1' fraglist, tipc should
update the packet 1' 'len' and 'data_len'. In my kernel(v3.10), it
doesn't do that, which was corrected in commit 5074a (v3.16).
Thanks for your patience
>
> include/linux/skbuff.h-/**
> include/linux/skbuff.h: * skb_tailroom - bytes at buffer end
> include/linux/skbuff.h- * @skb: buffer to check
> include/linux/skbuff.h- *
> include/linux/skbuff.h- * Return the number of bytes of free space at the tail of an sk_buff
> include/linux/skbuff.h- */
> include/linux/skbuff.h:static inline int skb_tailroom(const struct sk_buff *skb)
> include/linux/skbuff.h-{
> include/linux/skbuff.h- return skb_is_nonlinear(skb) ? 0 : skb->end - skb->tail;
> include/linux/skbuff.h-}
>
>
>
>
> .
>
prev parent reply other threads:[~2015-08-28 5:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 0:56 [PATCH net-next] net: Check frag_lists first to prevent data out of order chenweilong
2015-08-27 2:12 ` Eric Dumazet
2015-08-27 2:23 ` Eric Dumazet
2015-08-28 3:35 ` Weilong Chen
2015-08-28 4:26 ` David Miller
2015-08-28 5:34 ` Weilong Chen
2015-08-28 4:37 ` Eric Dumazet
2015-08-28 5:33 ` Weilong Chen [this message]
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=55DFF29A.1090208@huawei.com \
--to=chenweilong@huawei.com \
--cc=alexander.h.duyck@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
/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.