From: maowenan <maowenan@huawei.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net v2] tcp: avoid creating multiple req socks with the same tuples
Date: Fri, 14 Jun 2019 17:35:01 +0800 [thread overview]
Message-ID: <52025f94-04d3-2a44-11cd-7aa66ebc7e27@huawei.com> (raw)
In-Reply-To: <6aa69ab5-ed81-6a7f-2b2b-214e44ff0ada@gmail.com>
On 2019/6/14 12:28, Eric Dumazet wrote:
>
>
> On 6/13/19 9:19 PM, maowenan wrote:
>>
>>
>> @Eric, for this issue I only want to check TCP_NEW_SYN_RECV sk, is it OK like below?
>> + if (!osk && sk->sk_state == TCP_NEW_SYN_RECV)
>> + reqsk = __inet_lookup_established(sock_net(sk), &tcp_hashinfo,
>> + sk->sk_daddr, sk->sk_dport,
>> + sk->sk_rcv_saddr, sk->sk_num,
>> + sk->sk_bound_dev_if, sk->sk_bound_dev_if);
>> + if (unlikely(reqsk)) {
>>
>
> Not enough.
>
> If we have many cpus here, there is a chance another cpu has inserted a request socket, then
> replaced it by an ESTABLISH socket for the same 4-tuple.
I try to get more clear about the scene you mentioned. And I have do some testing about this, it can work well
when I use multiple cpus.
The ESTABLISH socket would be from tcp_check_req->tcp_v4_syn_recv_sock->tcp_create_openreq_child,
and for this path, inet_ehash_nolisten pass osk(NOT NULL), my patch won't call __inet_lookup_established in inet_ehash_insert().
When TCP_NEW_SYN_RECV socket try to inset to hash table, it will pass osk with NULL, my patch will check whether reqsk existed
in hash table or not. If reqsk is existed, it just removes this reqsk and dose not insert to hash table. Then the synack for this
reqsk can't be sent to client, and there is no chance to receive the ack from client, so ESTABLISH socket can't be replaced in hash table.
So I don't see the race when there are many cpus. Can you show me some clue?
thank you.
>
> We need to take the per bucket spinlock much sooner.
>
> And this is fine, all what matters is that we do no longer grab the listener spinlock.
>
>
next prev parent reply other threads:[~2019-06-14 9:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 3:57 Mao Wenan
2019-06-12 16:25 ` David Miller
2019-06-13 6:34 ` maowenan
2019-06-12 16:30 ` Eric Dumazet
2019-06-13 4:21 ` maowenan
2019-06-14 4:19 ` maowenan
2019-06-14 4:28 ` Eric Dumazet
2019-06-14 9:35 ` maowenan [this message]
2019-06-14 12:27 ` Eric Dumazet
2019-06-14 14:03 ` maowenan
2019-06-14 14:25 ` Eric Dumazet
2019-06-14 14:34 ` 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=52025f94-04d3-2a44-11cd-7aa66ebc7e27@huawei.com \
--to=maowenan@huawei.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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 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®