From: rajasimandalos@gmail.com
To: linux-cifs@vger.kernel.org
Cc: bharathsm@microsoft.com, msetiya@microsoft.com,
smfrench@gmail.com, sfrench@samba.org, stfrench@microsoft.com,
Rajasi Mandal <rajasimandal@microsoft.com>
Subject: [PATCH 3/9] smb: client: sync retrans on remount
Date: Thu, 2 Jul 2026 11:35:29 +0000 [thread overview]
Message-ID: <20260702113535.4044308-4-rajasimandalos@gmail.com> (raw)
In-Reply-To: <20260702113535.4044308-1-rajasimandalos@gmail.com>
From: Rajasi Mandal <rajasimandal@microsoft.com>
The retrans mount option controls how many times the client retries
sending a request before giving up. Although remount already stored
the new value in cifs_sb->ctx, it was never propagated to
server->retrans, so the running connection kept using the old count.
Introduce smb3_sync_server_opts() to push ctx options that live on
TCP_Server_Info into the live server struct after a successful
remount. For now it handles retrans; subsequent patches will extend
it to other server-level knobs.
The previous patch in this series ("smb: client: sync runtime state
into ctx on reconfigure") duplicates the existing context on remount,
so a bare 'mount -o remount' carries the old retrans value forward and
the parser only overwrites it when the user explicitly passes
retrans=N. No special-casing for the bare-remount /proc/mounts replay
is therefore needed; in particular, an explicit retrans=0 from the
user now correctly resets the value to the compile-time default.
Writes to server->retrans are unsynchronized to match the existing
convention: every other reader of the field (smb2ops.c retry path,
cifs_show_options(), the original cifs_get_tcp_session() writer) does
not take server->srv_lock, and match_server() only reads it under
srv_lock as part of the larger match function.
Note that retrans lives on TCP_Server_Info and is therefore shared
across all mounts to the same server; reconfiguring one mount updates
the value seen by every other mount sharing the connection. This is
consistent with the existing semantics: cifs_show_options() already
reads server->retrans for /proc/mounts on every mount, and the
runtime retry path always uses the server's value rather than any
per-mount copy.
Signed-off-by: Rajasi Mandal <rajasimandal@microsoft.com>
Reviewed-by: Meetakshi Setiya <msetiya@microsoft.com>
---
fs/smb/client/fs_context.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c
index d5a7d4dd402b..bfbea0648f6a 100644
--- a/fs/smb/client/fs_context.c
+++ b/fs/smb/client/fs_context.c
@@ -1278,6 +1278,24 @@ static void smb3_sync_ses_chan_max(struct cifs_ses *ses, size_t max_channels)
spin_unlock(&ses->chan_lock);
}
+/*
+ * Synchronize server-level options that are stored on TCP_Server_Info
+ * at mount time. These fields are consulted at runtime (retry logic)
+ * so remount needs to update the live server struct in addition to
+ * cifs_sb->ctx. Note these live on TCP_Server_Info and are therefore
+ * shared across all mounts to the same server; reconfiguring one mount
+ * updates the value seen by every other mount sharing the connection,
+ * matching how cifs_show_options() and the runtime retry path already
+ * read them unsynchronized from the server struct.
+ */
+static void smb3_sync_server_opts(struct cifs_sb_info *cifs_sb)
+{
+ struct TCP_Server_Info *server = cifs_sb_master_tcon(cifs_sb)->ses->server;
+ struct smb3_fs_context *ctx = cifs_sb->ctx;
+
+ server->retrans = ctx->retrans;
+}
+
static int smb3_reconfigure(struct fs_context *fc)
{
struct smb3_fs_context *ctx = smb3_fc2context(fc);
@@ -1447,6 +1465,8 @@ static int smb3_reconfigure(struct fs_context *fc)
if (!rc)
rc = dfs_cache_remount_fs(cifs_sb);
#endif
+ if (!rc)
+ smb3_sync_server_opts(cifs_sb);
return rc;
--
2.43.0
next prev parent reply other threads:[~2026-07-02 11:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 11:35 [PATCH RESEND 0/9] smb: client: remount reconfigure option fixes rajasimandalos
2026-07-02 11:35 ` [PATCH 1/9] smb: client: sync runtime state into ctx on reconfigure rajasimandalos
2026-07-02 11:35 ` [PATCH 2/9] smb: client: block non-reconfigurable option changes on remount rajasimandalos
2026-07-02 11:35 ` rajasimandalos [this message]
2026-07-02 11:35 ` [PATCH 4/9] smb: client: block cache=ro and cache=singleclient " rajasimandalos
2026-07-02 11:35 ` [PATCH 5/9] smb: client: apply rasize " rajasimandalos
2026-07-02 11:35 ` [PATCH 6/9] smb: client: move struct tcon_list to cifsglob.h rajasimandalos
2026-07-02 11:35 ` [PATCH 7/9] smb: client: allow nolease option to be reconfigured on remount rajasimandalos
2026-07-02 11:35 ` [PATCH 8/9] smb: client: review fixes for remount ctx/retrans sync (patches 1-4) rajasimandalos
2026-07-02 11:35 ` [PATCH 9/9] smb: client: review fixes for nolease remount (patch 7) rajasimandalos
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=20260702113535.4044308-4-rajasimandalos@gmail.com \
--to=rajasimandalos@gmail.com \
--cc=bharathsm@microsoft.com \
--cc=linux-cifs@vger.kernel.org \
--cc=msetiya@microsoft.com \
--cc=rajasimandal@microsoft.com \
--cc=sfrench@samba.org \
--cc=smfrench@gmail.com \
--cc=stfrench@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.