From: Alexandra Winter <wintera@linux.ibm.com>
To: "D. Wythe" <alibuda@linux.alibaba.com>,
Wenjia Zhang <wenjia@linux.ibm.com>,
kgraul@linux.ibm.com, jaka@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] net/smc: fix panic smc_tcp_syn_recv_sock() while closing listen socket
Date: Mon, 25 Sep 2023 11:43:33 +0200 [thread overview]
Message-ID: <3d1b5c12-971f-3464-5f28-79477f1f9eb2@linux.ibm.com> (raw)
In-Reply-To: <ee2a5f8c-4119-c84a-05bc-03015e6c9bea@linux.alibaba.com>
On 25.09.23 10:29, D. Wythe wrote:
> Hi Wenjia,
>
>>
>> this is unfortunately not sufficient for this fix. You have to make sure that is not a life-time problem. Even so, READ_ONCE() is also needed in this case.
>>
>
> Life-time problem? If you means the smc will still be NULL in the future, I don't really think so, smc is a local variable assigned by smc_clcsock_user_data.
> it's either NULL or a valid and unchanged value.
>
> And READ_ONCE() is needed indeed, considering not make too much change, maybe we can protected following
The local variable smc is a pointer to the smc_sock structure, so the question is whether you can just do a READ_ONCE
and then continue to use the content of the smc_sock structure, even though e.g. a smc_close_active() may be going on in
parallel.
>
> smc = smc_clcsock_user_data(sk);
>
> with sk_callback_lock, which solves the same problem. What do you think?
In af_ops.syn_recv_sock() and thus also in smc_tcp_syn_recv_sock()
sk is defined as const. So you cannot simply do take sk_callback_lock, that will create compiler errors.
(same for smc_hs_congested() BTW)
If you are sure the contents of *smc are always valid, then READ_ONCE is all you need.
Maybe it is better to take a step back and consider what needs to be protected when (lifetime).
Just some thoughts (there may be ramifications that I am not aware of):
Maybe clcsock->sk->sk_user_data could be set to point to smc_sock as soon as the clc socket is created?
Isn't the smc socket always valid as long as the clc socket exists?
Then sk_user_data would no longer indicate whether the callback functions were set to smc values, but would that matter?
Are there scenarios where it matters whether the old or the new callback function is called?
Why are the values restored in smc_close_active() if the clc socket is released shortly after anyhow?
You see I am wondering whether adding more locking, there is a way to make sure structures are safe to use.
next prev parent reply other threads:[~2023-09-25 10:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 12:08 [PATCH net] net/smc: fix panic smc_tcp_syn_recv_sock() while closing listen socket D. Wythe
2023-09-21 3:19 ` Dust Li
2023-09-21 21:43 ` Simon Horman
2023-09-21 23:59 ` Wenjia Zhang
2023-09-25 8:29 ` D. Wythe
2023-09-25 9:43 ` Alexandra Winter [this message]
2023-09-26 3:00 ` D. Wythe
2023-09-26 7:18 ` Alexandra Winter
2023-09-26 9:06 ` D. Wythe
2023-09-27 8:14 ` Alexandra Winter
2023-10-05 18:14 ` Wenjia Zhang
2023-10-08 8:22 ` D. Wythe
2023-10-11 12:39 ` Wenjia Zhang
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=3d1b5c12-971f-3464-5f28-79477f1f9eb2@linux.ibm.com \
--to=wintera@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=wenjia@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;
as well as URLs for NNTP newsgroup(s).