diff options
author | David Howells <dhowells@redhat.com> | 2024-04-04 18:05:19 +0300 |
---|---|---|
committer | Steve French <stfrench@microsoft.com> | 2024-04-19 23:37:47 +0300 |
commit | dad80c6bff770d25f67ec25fe011730e4a463008 (patch) | |
tree | 5fc5557eddfaeecaa96f2bf41a8954f38fc2d66b /lib/strscpy_kunit.c | |
parent | 0bbac3facb5d6cc0171c45c9873a2dc96bea9680 (diff) | |
download | linux-dad80c6bff770d25f67ec25fe011730e4a463008.tar.xz |
cifs: Fix reacquisition of volume cookie on still-live connection
During mount, cifs_mount_get_tcon() gets a tcon resource connection record
and then attaches an fscache volume cookie to it. However, it does this
irrespective of whether or not the tcon returned from cifs_get_tcon() is a
new record or one that's already in use. This leads to a warning about a
volume cookie collision and a leaked volume cookie because tcon->fscache
gets reset.
Fix this be adding a mutex and a "we've already tried this" flag and only
doing it once for the lifetime of the tcon.
[!] 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.
This can be reproduced simply by something like:
mount //example.com/test /xfstest.test -o user=shares,pass=xxx,fsc
mount //example.com/test /mnt -o user=shares,pass=xxx,fsc
Fixes: 70431bfd825d ("cifs: Support fscache indexing rewrite")
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
cc: Shyam Prasad N <sprasad@microsoft.com>
cc: linux-cifs@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Diffstat (limited to 'lib/strscpy_kunit.c')
0 files changed, 0 insertions, 0 deletions