From: David Howells <dhowells@redhat.com>
To: Paulo Alcantara <pc@manguebit.com>
Cc: dhowells@redhat.com, Steve French <sfrench@samba.org>,
Shyam Prasad N <sprasad@microsoft.com>,
linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live connection
Date: Wed, 17 Apr 2024 14:41:50 +0100 [thread overview]
Message-ID: <188149.1713361310@warthog.procyon.org.uk> (raw)
In-Reply-To: <14e66691a65e3d05d3d8d50e74dfb366@manguebit.com>
Paulo Alcantara <pc@manguebit.com> wrote:
> > [!] Note: Looking at cifs_mount_get_tcon(), a more general solution may
> > actually be required. Reacquiring the volume cookie isn't the only thing
> > that function does: it also partially reinitialises the tcon record without
> > any locking - which may cause live filesystem ops already using the tcon
> > through a previous mount to malfunction.
>
> Agreed.
Looking over the code again, I'm not sure whether is actually necessary - or
whether it is necessary and will be a bit nasty to implement as it will
require read locking also.
Firstly, reset_cifs_unix_caps() seems to re-set tcon->fsUnixInfo.Capability
and tcon->unix_ext, which it would presumably set to the same things - which
is probably fine.
However, cifs_qfs_tcon() makes RPC operations that reloads tcon->fsDevInfo and
tcon->fsAttrInfo - both of which may be being accessed without locks.
smb2_qfs_tcon() and smb3_qfs_tcon() alters everything cifs_qfs_tcon() does,
plus a bunch of extra tcon members. Can this locally cached information
change over time on the server whilst we have a connection to it?
David
prev parent reply other threads:[~2024-04-17 13:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 15:21 [PATCH] cifs: Fix reacquisition of volume cookie on still-live connection David Howells
2024-04-04 16:07 ` Paulo Alcantara
2024-04-16 16:58 ` David Howells
2024-04-17 14:09 ` Paulo Alcantara
2024-04-17 14:38 ` David Howells
2024-04-17 18:59 ` Tom Talpey
2024-04-18 13:32 ` David Howells
2024-04-17 21:25 ` Paulo Alcantara
2024-04-18 13:43 ` David Howells
2024-04-19 20:04 ` Paulo Alcantara
2024-04-17 13:41 ` David Howells [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=188149.1713361310@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pc@manguebit.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.