From: Wenjia Zhang <wenjia@linux.ibm.com>
To: "D. Wythe" <alibuda@linux.alibaba.com>,
kgraul@linux.ibm.com, jaka@linux.ibm.com, wintera@linux.ibm.com
Cc: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org
Subject: Re: [PATCH net 4/5] net/smc: protect connection state transitions in listen work
Date: Thu, 12 Oct 2023 19:14:35 +0200 [thread overview]
Message-ID: <52133656-4dc6-4f32-9881-b63f19bb8859@linux.ibm.com> (raw)
In-Reply-To: <1697009600-22367-5-git-send-email-alibuda@linux.alibaba.com>
On 11.10.23 09:33, D. Wythe wrote:
> From: "D. Wythe" <alibuda@linux.alibaba.com>
>
> Consider the following scenario:
>
> smc_close_passive_work
> smc_listen_out_connected
> lock_sock()
> if (state == SMC_INIT)
> if (state == SMC_INIT)
> state = SMC_APPCLOSEWAIT1;
> state = SMC_ACTIVE
> release_sock()
>
> This would cause the state machine of the connection to be corrupted.
> Also, this issue can occur in smc_listen_out_err().
>
> To solve this problem, we can protect the state transitions under
> the lock of sock to avoid collision.
>
To this fix, I have to repeat the question from Alexandra.
Did the scenario occur in real life? Or is it just kind of potencial
problem you found during the code review?
If it is the former one, could you please show us the corresponding
message, e.g. from dmesg? If it is the latter one, I'd like to deal with
it more carefully. Going from this scenario, I noticed that there could
also be other similar places where we need to make sure that no race
happens. Thus, it would make more sense to find a systematic approach.
> Fixes: 3b2dec2603d5 ("net/smc: restructure client and server code in af_smc")
> Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
> ---
> net/smc/af_smc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 5ad2a9f..3bb8265 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1926,8 +1926,10 @@ static void smc_listen_out_connected(struct smc_sock *new_smc)
> {
> struct sock *newsmcsk = &new_smc->sk;
>
> + lock_sock(newsmcsk);
> if (newsmcsk->sk_state == SMC_INIT)
> newsmcsk->sk_state = SMC_ACTIVE;
> + release_sock(newsmcsk);
>
> smc_listen_out(new_smc);
> }
> @@ -1939,9 +1941,12 @@ static void smc_listen_out_err(struct smc_sock *new_smc)
> struct net *net = sock_net(newsmcsk);
>
> this_cpu_inc(net->smc.smc_stats->srv_hshake_err_cnt);
> +
> + lock_sock(newsmcsk);
> if (newsmcsk->sk_state == SMC_INIT)
> sock_put(&new_smc->sk); /* passive closing */
> newsmcsk->sk_state = SMC_CLOSED;
> + release_sock(newsmcsk);
>
> smc_listen_out(new_smc);
> }
next prev parent reply other threads:[~2023-10-12 17:14 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 7:33 [PATCH net 0/5] net/smc: bugfixs for smc-r D. Wythe
2023-10-11 7:33 ` [PATCH net 1/5] net/smc: fix dangling sock under state SMC_APPFINCLOSEWAIT D. Wythe
2023-10-11 14:00 ` Dust Li
2023-10-11 20:31 ` Wenjia Zhang
2023-10-12 2:47 ` D. Wythe
[not found] ` <f8089b26-bb11-f82d-8070-222b1f8c1db1@linux.alibaba.com>
2023-10-12 11:51 ` Wenjia Zhang
2023-10-13 5:32 ` Dust Li
2023-10-13 11:52 ` Wenjia Zhang
2023-10-13 12:27 ` Dust Li
2023-10-17 2:00 ` D. Wythe
2023-10-17 8:39 ` Dust Li
2023-10-17 17:03 ` Wenjia Zhang
[not found] ` <4065e94f-f7ea-7943-e2cc-0c7d3f9c788b@linux.alibaba.com>
2023-10-19 11:54 ` Wenjia Zhang
2023-10-23 20:53 ` Wenjia Zhang
2023-10-11 7:33 ` [PATCH net 2/5] net/smc: fix incorrect barrier usage D. Wythe
2023-10-11 8:44 ` Heiko Carstens
2023-10-11 8:57 ` D. Wythe
2023-10-11 7:33 ` [PATCH net 3/5] net/smc: allow cdc msg send rather than drop it with NULL sndbuf_desc D. Wythe
2023-10-11 20:37 ` Wenjia Zhang
2023-10-12 2:49 ` D. Wythe
2023-10-12 15:15 ` Wenjia Zhang
2023-10-11 7:33 ` [PATCH net 4/5] net/smc: protect connection state transitions in listen work D. Wythe
2023-10-12 17:14 ` Wenjia Zhang [this message]
2023-10-31 3:04 ` D. Wythe
2023-10-11 7:33 ` [PATCH net 5/5] net/smc: put sk reference if close work was canceled D. Wythe
2023-10-11 14:54 ` Dust Li
2023-10-12 19:04 ` Wenjia Zhang
[not found] ` <ee641ca5-104b-d1ec-5b2a-e20237c5378a@linux.alibaba.com>
2023-10-18 20:26 ` Wenjia Zhang
2023-10-19 7:33 ` D. Wythe
2023-10-19 17:40 ` Wenjia Zhang
2023-10-20 2:41 ` D. Wythe
2023-10-23 8:19 ` Wenjia Zhang
2023-10-23 8:52 ` D. Wythe
2023-10-23 10:28 ` Wenjia Zhang
2023-10-23 11:56 ` Dust Li
[not found] ` <59c0c75f-e9df-2ef1-ead2-7c5c97f3e750@linux.alibaba.com>
2023-10-23 20:52 ` Wenjia Zhang
2023-10-12 13:43 ` [PATCH net 0/5] net/smc: bugfixs for smc-r Alexandra Winter
2023-10-17 1:56 ` D. Wythe
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=52133656-4dc6-4f32-9881-b63f19bb8859@linux.ibm.com \
--to=wenjia@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=jaka@linux.ibm.com \
--cc=kgraul@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=wintera@linux.ibm.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