Hi Dave, David Howells <dhowells@xxxxxxxxxx> writes: > 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. Can't we just move the cookie acquisition to cifs_get_tcon() before it gets added to list @ses->tcon_list. This way we'll guarantee that the cookie is set only once for the new tcon. Besides, do we want to share a tcon with two different superblocks that have 'fsc' and 'nofsc', respectively? If not, it would be better to fix match_tcon() as well to handle such case. > [!] 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.
