<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/fs/cifs/connect.c, branch master</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2023-05-24T21:29:21+00:00</updated>
<entry>
<title>smb: move client and server files to common directory fs/smb</title>
<updated>2023-05-24T21:29:21+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-05-22T01:46:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=38c8a9a52082579090e34c033d439ed2cd1a462d'/>
<id>urn:sha1:38c8a9a52082579090e34c033d439ed2cd1a462d</id>
<content type='text'>
Move CIFS/SMB3 related client and server files (cifs.ko and ksmbd.ko
and helper modules) to new fs/smb subdirectory:

   fs/cifs --&gt; fs/smb/client
   fs/ksmbd --&gt; fs/smb/server
   fs/smbfs_common --&gt; fs/smb/common

Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Acked-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>smb3: fix problem remounting a share after shutdown</title>
<updated>2023-05-09T14:54:58+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-05-09T06:37:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=716a3cf317456fa01d54398bb14ab354f50ed6a2'/>
<id>urn:sha1:716a3cf317456fa01d54398bb14ab354f50ed6a2</id>
<content type='text'>
xfstests generic/392 showed a problem where even after a
shutdown call was made on a mount, we would still attempt
to use the (now inaccessible) superblock if another mount
was attempted for the same share.

Reported-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 087f757b0129 ("cifs: add shutdown support")
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: fix sharing of DFS connections</title>
<updated>2023-05-04T21:54:44+00:00</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.com</email>
</author>
<published>2023-04-24T02:26:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8e3554150d6c80a84b3cb046615d1a0e943811dc'/>
<id>urn:sha1:8e3554150d6c80a84b3cb046615d1a0e943811dc</id>
<content type='text'>
When matching DFS connections, we can't rely on the values set in
cifs_sb_info::prepath and cifs_tcon::tree_name as they might change
during DFS failover.  The DFS referrals related to a specific DFS tcon
are already matched earlier in match_server(), therefore we can safely
skip those checks altogether as the connection is guaranteed to be
unique for the DFS tcon.

Besides, when creating or finding an SMB session, make sure to also
refcount any DFS root session related to it (cifs_ses::dfs_root_ses),
so if a new DFS mount ends up reusing the connection from the old
mount while there was an umount(2) still in progress (e.g. umount(2)
-&gt; cifs_umount() -&gt; reconnect -&gt; cifs_put_tcon()), the connection
could potentially be put right after the umount(2) finished.

Patch has minor update to include fix for unused variable issue
noted by the kernel test robot

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Link: https://lore.kernel.org/oe-kbuild-all/202305041040.j7W2xQSy-lkp@intel.com/
Cc: stable@vger.kernel.org # v6.2+
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: avoid potential races when handling multiple dfs tcons</title>
<updated>2023-05-04T04:29:47+00:00</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.com</email>
</author>
<published>2023-04-27T07:40:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6be2ea33a4093402252724a00c4af8033725184c'/>
<id>urn:sha1:6be2ea33a4093402252724a00c4af8033725184c</id>
<content type='text'>
Now that a DFS tcon manages its own list of DFS referrals and
sessions, there is no point in having a single worker to refresh
referrals of all DFS tcons.  Make it faster and less prone to race
conditions when having several mounts by queueing a worker per DFS
tcon that will take care of refreshing only the DFS referrals related
to it.

Cc: stable@vger.kernel.org # v6.2+
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: protect access of TCP_Server_Info::{origin,leaf}_fullpath</title>
<updated>2023-05-04T04:29:39+00:00</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.com</email>
</author>
<published>2023-04-26T16:43:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3dc9c433c9dde15477d02b609ccb4328e2adb6dc'/>
<id>urn:sha1:3dc9c433c9dde15477d02b609ccb4328e2adb6dc</id>
<content type='text'>
Protect access of TCP_Server_Info::{origin,leaf}_fullpath when
matching DFS connections, and get rid of
TCP_Server_Info::current_fullpath while we're at it.

Cc: stable@vger.kernel.org # v6.2+
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: fix potential use-after-free bugs in TCP_Server_Info::hostname</title>
<updated>2023-05-02T14:41:09+00:00</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.com</email>
</author>
<published>2023-04-21T18:52:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=90c49fce1c43e1cc152695e20363ff5087897c09'/>
<id>urn:sha1:90c49fce1c43e1cc152695e20363ff5087897c09</id>
<content type='text'>
TCP_Server_Info::hostname may be updated once or many times during
reconnect, so protect its access outside reconnect path as well and
then prevent any potential use-after-free bugs.

Cc: stable@vger.kernel.org
Signed-off-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: missing lock when updating session status</title>
<updated>2023-04-29T02:23:42+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-04-27T03:01:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=943fb67b090212f1d3789eb7796b1c9045c62fd6'/>
<id>urn:sha1:943fb67b090212f1d3789eb7796b1c9045c62fd6</id>
<content type='text'>
Coverity noted a place where we were not grabbing
the ses_lock when setting (and checking) ses_status.

Addresses-Coverity: 1536833 ("Data race condition (MISSING_LOCK)")
Reviewed-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Reviewed-by: Bharath SM &lt;bharathsm@microsoft.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>smb3: fix unusable share after force unmount failure</title>
<updated>2023-03-24T19:37:12+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2023-03-23T21:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=491eafce1a51c457701351a4bf40733799745314'/>
<id>urn:sha1:491eafce1a51c457701351a4bf40733799745314</id>
<content type='text'>
If user does forced unmount ("umount -f") while files are still open
on the share (as was seen in a Kubernetes example running on SMB3.1.1
mount) then we were marking the share as "TID_EXITING" in umount_begin()
which caused all subsequent operations (except write) to fail ... but
unfortunately when umount_begin() is called we do not know yet that
there are open files or active references on the share that would prevent
unmount from succeeding.  Kubernetes had example when they were doing
umount -f when files were open which caused the share to become
unusable until the files were closed (and the umount retried).

Fix this so that TID_EXITING is not set until we are about to send
the tree disconnect (not at the beginning of forced umounts in
umount_begin) so that if "umount -f" fails (due to open files or
references) the mount is still usable.

Cc: stable@vger.kernel.org
Reviewed-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Reviewed-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: avoid race conditions with parallel reconnects</title>
<updated>2023-03-24T14:03:55+00:00</updated>
<author>
<name>Shyam Prasad N</name>
<email>sprasad@microsoft.com</email>
</author>
<published>2023-03-20T06:08:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bc962159e8e326af634a506508034a375bf2b858'/>
<id>urn:sha1:bc962159e8e326af634a506508034a375bf2b858</id>
<content type='text'>
When multiple processes/channels do reconnects in parallel
we used to return success immediately
negotiate/session-setup/tree-connect, causing race conditions
between processes that enter the function in parallel.
This caused several errors related to session not found to
show up during parallel reconnects.

Signed-off-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Reviewed-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: lock chan_lock outside match_session</title>
<updated>2023-03-23T04:15:40+00:00</updated>
<author>
<name>Shyam Prasad N</name>
<email>sprasad@microsoft.com</email>
</author>
<published>2023-02-20T13:02:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2f4e429c846972c8405951a9ff7a82aceeca7461'/>
<id>urn:sha1:2f4e429c846972c8405951a9ff7a82aceeca7461</id>
<content type='text'>
Coverity had rightly indicated a possible deadlock
due to chan_lock being done inside match_session.
All callers of match_* functions should pick up the
necessary locks and call them.

Signed-off-by: Shyam Prasad N &lt;sprasad@microsoft.com&gt;
Reviewed-by: Paulo Alcantara (SUSE) &lt;pc@manguebit.com&gt;
Cc: stable@vger.kernel.org
Fixes: 724244cdb382 ("cifs: protect session channel fields with chan_lock")
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
</feed>
