From: nspmangalore@gmail.com
To: linux-cifs@vger.kernel.org, smfrench@gmail.com, pc@manguebit.org,
bharathsm@microsoft.com
Cc: Shyam Prasad N <sprasad@microsoft.com>
Subject: [PATCH 1/2] cifs: Corrections to lock ordering notes
Date: Sat, 31 Jan 2026 13:32:15 +0530 [thread overview]
Message-ID: <20260131080239.943483-1-sprasad@microsoft.com> (raw)
From: Shyam Prasad N <sprasad@microsoft.com>
There were a couple of discrepencies in lock ordering for the locks
that were specified in the lock ordering notes. Did an analysis
of the current codebase (using LLM) and found two pairs whose ordering
in these notes were wrong. It also found one lock that was recently
removed, and a few locks that weren't documented here before.
Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
---
fs/smb/client/cifsglob.h | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/fs/smb/client/cifsglob.h b/fs/smb/client/cifsglob.h
index 3eca5bfb70303..d797b953b6cf6 100644
--- a/fs/smb/client/cifsglob.h
+++ b/fs/smb/client/cifsglob.h
@@ -1943,6 +1943,8 @@ require use of the stronger protocol */
*/
/****************************************************************************
+ * LOCK ORDERING NOTES:
+ ****************************************************************************
* Here are all the locks (spinlock, mutex, semaphore) in cifs.ko, arranged according
* to the locking order. i.e. if two locks are to be held together, the lock that
* appears higher in this list needs to be taken before the other.
@@ -1971,18 +1973,21 @@ require use of the stronger protocol */
* =====================================================================================
* Lock Protects Initialization fn
* =====================================================================================
+ * cifs_mount_mutex mount/unmount operations
* vol_list_lock
* vol_info->ctx_lock vol_info->ctx
* cifs_sb_info->tlink_tree_lock cifs_sb_info->tlink_tree cifs_setup_cifs_sb
* TCP_Server_Info-> TCP_Server_Info cifs_get_tcp_session
* reconnect_mutex
- * TCP_Server_Info->srv_mutex TCP_Server_Info cifs_get_tcp_session
* cifs_ses->session_mutex cifs_ses sesInfoAlloc
+ * TCP_Server_Info->_srv_mutex TCP_Server_Info cifs_get_tcp_session
+ * cifs_tcp_ses_lock cifs_tcp_ses_list sesInfoAlloc
* cifs_tcon->open_file_lock cifs_tcon->openFileList tconInfoAlloc
* cifs_tcon->pending_opens
* cifs_tcon->stat_lock cifs_tcon->bytes_read tconInfoAlloc
* cifs_tcon->bytes_written
- * cifs_tcp_ses_lock cifs_tcp_ses_list sesInfoAlloc
+ * cifs_tcon->fscache_lock cifs_tcon->fscache tconInfoAlloc
+ * cifs_tcon->sb_list_lock cifs_tcon->cifs_sb_list tconInfoAlloc
* GlobalMid_Lock GlobalMaxActiveXid init_cifs
* GlobalCurrentXid
* GlobalTotalActiveXid
@@ -2005,6 +2010,8 @@ require use of the stronger protocol */
* ->chans_in_reconnect
* cifs_tcon->tc_lock (anything that is not protected by another lock and can change)
* tcon_info_alloc
+ * cifs_swnreg_idr_mutex cifs_swnreg_idr cifs_swn.c
+ * (witness service registration, accesses tcon fields under tc_lock)
* inode->i_rwsem, taken by fs/netfs/locking.c e.g. should be taken before cifsInodeInfo locks
* cifsInodeInfo->open_file_lock cifsInodeInfo->openFileList cifs_alloc_inode
* cifsInodeInfo->writers_lock cifsInodeInfo->writers cifsInodeInfo_alloc
@@ -2012,12 +2019,12 @@ require use of the stronger protocol */
* ->can_cache_brlcks
* cifsInodeInfo->deferred_lock cifsInodeInfo->deferred_closes cifsInodeInfo_alloc
* cached_fids->cfid_list_lock cifs_tcon->cfids->entries init_cached_dirs
- * cached_fid->fid_lock (anything that is not protected by another lock and can change)
- * init_cached_dir
+ * cached_fid->dirents.de_mutex cached_fid->dirents alloc_cached_dir
* cifsFileInfo->fh_mutex cifsFileInfo cifs_new_fileinfo
* cifsFileInfo->file_info_lock cifsFileInfo->count cifs_new_fileinfo
* ->invalidHandle initiate_cifs_search
* ->oplock_break_cancelled
+ * smbdirect_mr->mutex RDMA memory region management (SMBDirect only)
* mid_q_entry->mid_lock mid_q_entry->callback alloc_mid
* smb2_mid_entry_alloc
* (Any fields of mid_q_entry that will need protection)
--
2.43.0
next reply other threads:[~2026-01-31 8:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-31 8:02 nspmangalore [this message]
2026-01-31 8:02 ` [PATCH 2/2] cifs: Fix locking usage for tcon fields nspmangalore
2026-01-31 10:07 ` Shyam Prasad N
2026-01-31 14:58 ` kernel test robot
2026-01-31 15:50 ` kernel test robot
2026-01-31 15:54 ` kernel test robot
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=20260131080239.943483-1-sprasad@microsoft.com \
--to=nspmangalore@gmail.com \
--cc=bharathsm@microsoft.com \
--cc=linux-cifs@vger.kernel.org \
--cc=pc@manguebit.org \
--cc=smfrench@gmail.com \
--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