From: Tom Talpey <tom@talpey.com>
To: Tuo Li <islituo@gmail.com>,
sfrench@samba.org, pc@manguebit.com, lsahlber@redhat.com,
sprasad@microsoft.com
Cc: linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org, baijiaju1990@outlook.com,
BassCheck <bass@buaa.edu.cn>
Subject: Re: [PATCH v2] smb: fix a possible data race in cifs_can_echo()
Date: Thu, 15 Jun 2023 09:12:11 -0400 [thread overview]
Message-ID: <a7fd0996-ceec-54d0-b87b-09cf07bfb7fe@talpey.com> (raw)
In-Reply-To: <20230615063853.15500-1-islituo@gmail.com>
On 6/15/2023 2:38 AM, Tuo Li wrote:
> The struct field TCP_Server_Info.tcpStatus is often protected by the lock
> srv_lock when is accessed. Here is an example in __cifs_reconnect():
>
> spin_lock(&server->srv_lock);
> if (server->tcpStatus != CifsExiting)
> server->tcpStatus = CifsNeedNegotiate;
> spin_unlock(&server->srv_lock);
>
> However, the variable server->tcpStatus is accessed without holding the
> lock server->srv_lock in cifs_can_echo():
>
> if (server->tcpStatus == CifsGood)
> return true;
>
> To fix this possible data race, a lock and unlock pair is added when
> accessing the variable server->tcpStatus.
This is a NAK from me. The tcpStatus field is not being modified
here, and the race is trivial because the lock you propose is
dropped immediately either way.
Besides, this is SMB1, and the entirely unimportant ECHO procedure.
Tom.
> Reported-by: BassCheck <bass@buaa.edu.cn>
> Signed-off-by: Tuo Li <islituo@gmail.com>
> ---
> v2:
> * Release the lock server->srv_lock in the false branch.
> ---
> fs/smb/client/smb1ops.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/smb/client/smb1ops.c b/fs/smb/client/smb1ops.c
> index 7d1b3fc014d9..5120241d3c0e 100644
> --- a/fs/smb/client/smb1ops.c
> +++ b/fs/smb/client/smb1ops.c
> @@ -1049,8 +1049,12 @@ cifs_dir_needs_close(struct cifsFileInfo *cfile)
> static bool
> cifs_can_echo(struct TCP_Server_Info *server)
> {
> - if (server->tcpStatus == CifsGood)
> + spin_lock(&server->srv_lock);
> + if (server->tcpStatus == CifsGood) {
> + spin_unlock(&server->srv_lock);
> return true;
> + }
> + spin_unlock(&server->srv_lock);
>
> return false;
> }
prev parent reply other threads:[~2023-06-15 13:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 6:38 Tuo Li
2023-06-15 13:12 ` Tom Talpey [this message]
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=a7fd0996-ceec-54d0-b87b-09cf07bfb7fe@talpey.com \
--to=tom@talpey.com \
--cc=baijiaju1990@outlook.com \
--cc=bass@buaa.edu.cn \
--cc=islituo@gmail.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsahlber@redhat.com \
--cc=pc@manguebit.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.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®