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$(echo .)com \
--cc=alexander.h.duyck@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=hannes@stressinduktion$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=willemb@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox