From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <kerneljasonxing@gmail.com>
Cc: <davem@davemloft.net>, <dsahern@kernel.org>,
<edumazet@google.com>, <kernelxing@tencent.com>,
<kuba@kernel.org>, <kuniyu@amazon.com>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<pabeni@redhat.com>, <yoshfuji@linux-ipv6.org>
Subject: Re: [PATCH v6 net] tcp: avoid the lookup process failing to get sk in ehash table
Date: Tue, 17 Jan 2023 10:41:40 -0800 [thread overview]
Message-ID: <20230117184140.7010-1-kuniyu@amazon.com> (raw)
In-Reply-To: <20230117175340.91712-1-kerneljasonxing@gmail.com>
From: Jason Xing <kerneljasonxing@gmail.com>
Date: Wed, 18 Jan 2023 01:53:40 +0800
> From: Jason Xing <kernelxing@tencent.com>
>
> While one cpu is working on looking up the right socket from ehash
> table, another cpu is done deleting the request socket and is about
> to add (or is adding) the big socket from the table. It means that
> we could miss both of them, even though it has little chance.
>
> Let me draw a call trace map of the server side.
> CPU 0 CPU 1
> ----- -----
> tcp_v4_rcv() syn_recv_sock()
> inet_ehash_insert()
> -> sk_nulls_del_node_init_rcu(osk)
> __inet_lookup_established()
> -> __sk_nulls_add_node_rcu(sk, list)
>
> Notice that the CPU 0 is receiving the data after the final ack
> during 3-way shakehands and CPU 1 is still handling the final ack.
>
> Why could this be a real problem?
> This case is happening only when the final ack and the first data
> receiving by different CPUs. Then the server receiving data with
> ACK flag tries to search one proper established socket from ehash
> table, but apparently it fails as my map shows above. After that,
> the server fetches a listener socket and then sends a RST because
> it finds a ACK flag in the skb (data), which obeys RST definition
> in RFC 793.
>
> Besides, Eric pointed out there's one more race condition where it
> handles tw socket hashdance. Only by adding to the tail of the list
> before deleting the old one can we avoid the race if the reader has
> already begun the bucket traversal and it would possibly miss the head.
>
> Many thanks to Eric for great help from beginning to end.
>
> Fixes: 5e0724d027f0 ("tcp/dccp: fix hashdance race for passive sessions")
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
> Link: https://lore.kernel.org/lkml/20230112065336.41034-1-kerneljasonxing@gmail.com/
> ---
> v3,4,5,6:
> 1) nit: adjust the coding style.
>
> v2:
> 1) add the sk node into the tail of list to prevent the race.
> 2) fix the race condition when handling time-wait socket hashdance.
> ---
> net/ipv4/inet_hashtables.c | 17 +++++++++++++++--
> net/ipv4/inet_timewait_sock.c | 12 ++++++------
> 2 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
> index 24a38b56fab9..f58d73888638 100644
> --- a/net/ipv4/inet_hashtables.c
> +++ b/net/ipv4/inet_hashtables.c
> @@ -650,8 +650,20 @@ bool inet_ehash_insert(struct sock *sk, struct sock *osk, bool *found_dup_sk)
> spin_lock(lock);
> if (osk) {
> WARN_ON_ONCE(sk->sk_hash != osk->sk_hash);
> - ret = sk_nulls_del_node_init_rcu(osk);
> - } else if (found_dup_sk) {
> + ret = sk_hashed(osk);
> + if (ret) {
> + /* Before deleting the node, we insert a new one to make
> + * sure that the look-up-sk process would not miss either
> + * of them and that at least one node would exist in ehash
> + * table all the time. Otherwise there's a tiny chance
> + * that lookup process could find nothing in ehash table.
> + */
> + __sk_nulls_add_node_tail_rcu(sk, list);
> + sk_nulls_del_node_init_rcu(osk);
> + }
> + goto unlock;
> + }
> + if (found_dup_sk) {
> *found_dup_sk = inet_ehash_lookup_by_sk(sk, list);
> if (*found_dup_sk)
> ret = false;
> @@ -660,6 +672,7 @@ bool inet_ehash_insert(struct sock *sk, struct sock *osk, bool *found_dup_sk)
> if (ret)
> __sk_nulls_add_node_rcu(sk, list);
>
> +unlock:
> spin_unlock(lock);
>
> return ret;
> diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
> index 1d77d992e6e7..b66f2dea5a78 100644
> --- a/net/ipv4/inet_timewait_sock.c
> +++ b/net/ipv4/inet_timewait_sock.c
> @@ -91,20 +91,20 @@ void inet_twsk_put(struct inet_timewait_sock *tw)
> }
> EXPORT_SYMBOL_GPL(inet_twsk_put);
>
> -static void inet_twsk_add_node_rcu(struct inet_timewait_sock *tw,
> - struct hlist_nulls_head *list)
> +static void inet_twsk_add_node_tail_rcu(struct inet_timewait_sock *tw,
> + struct hlist_nulls_head *list)
> {
> - hlist_nulls_add_head_rcu(&tw->tw_node, list);
> + hlist_nulls_add_tail_rcu(&tw->tw_node, list);
> }
>
> static void inet_twsk_add_bind_node(struct inet_timewait_sock *tw,
> - struct hlist_head *list)
> + struct hlist_head *list)
> {
> hlist_add_head(&tw->tw_bind_node, list);
> }
>
> static void inet_twsk_add_bind2_node(struct inet_timewait_sock *tw,
> - struct hlist_head *list)
> + struct hlist_head *list)
> {
> hlist_add_head(&tw->tw_bind2_node, list);
> }
You need not change inet_twsk_add_bind_node() and
inet_twsk_add_bind2_node().
Thanks,
Kuniyuki
> @@ -147,7 +147,7 @@ void inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
>
> spin_lock(lock);
>
> - inet_twsk_add_node_rcu(tw, &ehead->chain);
> + inet_twsk_add_node_tail_rcu(tw, &ehead->chain);
>
> /* Step 3: Remove SK from hash chain */
> if (__sk_nulls_del_node_init_rcu(sk))
> --
> 2.37.3
next prev parent reply other threads:[~2023-01-17 19:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 17:53 Jason Xing
2023-01-17 18:41 ` Kuniyuki Iwashima [this message]
2023-01-18 0:52 ` Jason Xing
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=20230117184140.7010-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yoshfuji@linux-ipv6.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®