From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jason Xing <kerneljasonxing@gmail.com>,
David Miller <davem@davemloft.net>,
kuba@kernel.org, alobakin@pm.me, jonathan.lemon@gmail.com,
Willem de Bruijn <willemb@google.com>,
pabeni@redhat.com, vvs@virtuozzo.com, cong.wang@bytedance.com
Cc: netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jason Xing <xingwanli@kuaishou.com>
Subject: Re: [PATCH net] net: gro: set the last skb->next to NULL when it get merged
Date: Wed, 27 Oct 2021 12:25:33 -0700 [thread overview]
Message-ID: <1b40f49d-1dd0-5bec-2a08-f55ac3529da3@gmail.com> (raw)
In-Reply-To: <CAL+tcoAD+iiEFbvMnaHjg_-42_r7ukxDt8CveYW7pE4arcdKsg@mail.gmail.com>
On 10/27/21 1:07 AM, Jason Xing wrote:
> On Wed, Oct 27, 2021 at 3:23 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
>>
>> On Tue, Oct 26, 2021 at 9:19 PM <kerneljasonxing@gmail.com> wrote:
>>>
>>> From: Jason Xing <xingwanli@kuaishou.com>
>>>
>>> Setting the @next of the last skb to NULL to prevent the panic in future
>>> when someone does something to the last of the gro list but its @next is
>>> invalid.
>>>
>>> For example, without the fix (commit: ece23711dd95), a panic could happen
>>> with the clsact loaded when skb is redirected and then validated in
>>> validate_xmit_skb_list() which could access the error addr of the @next
>>> of the last skb. Thus, "general protection fault" would appear after that.
>>>
>>> Signed-off-by: Jason Xing <xingwanli@kuaishou.com>
>>> ---
>>> net/core/skbuff.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>>> index 2170bea..7b248f1 100644
>>> --- a/net/core/skbuff.c
>>> +++ b/net/core/skbuff.c
>>> @@ -4396,6 +4396,7 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)
>>> skb_shinfo(p)->frag_list = skb;
>>> else
>>> NAPI_GRO_CB(p)->last->next = skb;
>>> + skb->next = NULL;
>>> NAPI_GRO_CB(p)->last = skb;
>>
>> Besides, I'm a little bit confused that this operation inserts the
>> newest skb into the tail of the flow, so the tail of flow is the
>> newest, head oldest. The patch (commit: 600adc18) introduces the flush
>> of the oldest when the flow is full to lower the latency, but actually
>> it fetches the tail of the flow. Do I get something wrong here? I feel
>
> I have to update this part. The commit 600adc18 evicts and flushes the
> oldest flow. But for the current kernel, when
> "napi->gro_hash[hash].count >= MAX_GRO_SKBS" happens, the
> gro_flush_oldest() flushes the oldest skb of one certain flow,
> actually it is the newest skb because it is at the end of the list.
GRO only keeps one skb per flow in the main hash/lru.
I think you are not understanding GRO correctly.
next prev parent reply other threads:[~2021-10-27 19:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-26 13:18 kerneljasonxing
2021-10-27 7:23 ` Jason Xing
2021-10-27 8:07 ` Jason Xing
2021-10-27 8:56 ` Jason Xing
2021-10-27 12:40 ` Yunsheng Lin
2021-10-27 12:54 ` Jason Xing
2021-10-27 13:57 ` Jason Xing
2021-10-27 19:25 ` Eric Dumazet [this message]
2021-10-27 19:20 ` Eric Dumazet
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=1b40f49d-1dd0-5bec-2a08-f55ac3529da3@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=alobakin@pm.me \
--cc=cong.wang@bytedance.com \
--cc=davem@davemloft.net \
--cc=jonathan.lemon@gmail.com \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vvs@virtuozzo.com \
--cc=willemb@google.com \
--cc=xingwanli@kuaishou.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®