From: Enzo Matsumiya <ematsumiya@suse.de>
To: Steve French <smfrench@gmail.com>
Cc: Chunjie Zhu <chunjie.zhu@citrix.com>,
Steve French <sfrench@samba.org>,
Paulo Alcantara <pc@manguebit.com>,
Ronnie Sahlberg <lsahlber@redhat.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Tom Talpey <tom@talpey.com>,
linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix smb client defer close causes file corruption
Date: Wed, 24 Jun 2026 01:19:25 -0300 [thread overview]
Message-ID: <ajtavBgQP79ajERS@suse.de> (raw)
In-Reply-To: <CAH2r5mu7sdqJ4NJQzsqhY+3LmHE7AcREM9nYAbEZCNZ08yEafA@mail.gmail.com>
On 06/23, Steve French wrote:
>Do you see different behavior of this to different servers (Samba,
>Windows, ksmbd, Azure xSMB etc)?
>
>Disabling deferred close carries metadata integrity issues because it
>will lead users to set actimeo (or acregmax) to higher values, and
>disabling deferred close could significantly hurt performance for some
>common workload patterns (open/write/close/open/read/close e.g.)
>
>Other narrower client fixes for this presumably could be done, e.g.
>forcing close on the deferred close when rename a hardlink.
That looks like a safe measure to have IMO.
Cheers,
Enzo
>On Mon, Jun 22, 2026 at 4:40 AM Chunjie Zhu <chunjie.zhu@citrix.com> wrote:
>>
>> Test environment
>>
>> 4 hosts as smb client, 1 host as smb server
>> smb client hosts, kernel 6.6.138
>> mount options,
>> //10.70.48.15/xxx /run/xxx cifs rw,relatime,vers=3.0,
>> cache=loose,username=xxx,domain=xxx,uid=0,noforceuid,
>> gid=0,noforcegid,addr=10.70.48.15,file_mode=0755,
>> dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,
>> rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,
>> actimeo=0,closetimeo=1
>>
>> Work around
>>
>> mount with cache=none or closetimeo=0
>>
>> The Race Condition Flow
>>
>> Step 1: Host-01 closes file
>>
>> Host-01:
>> file close (eeefe8d0.vhd)
>> -> CIFS defers SMB2 CLOSE
>> -> Handle H1 stored in deferred_closes list
>> -> Lease L1 (RWH or RH) still active on server
>> -> Entry: { path=“eeefe8d0.vhd”, handle=H1, inode=I1 }
>>
>> Step 2: Host-02 does hardlink and rename
>>
>> Host-02:
>> hardlink(eeefe8d0.vhd, 0f11b74e.vhd)
>> -> SMB2: Creates new name for same inode
>> -> Server: inode I1 now has 2 names (link count = 2)
>> -> Host-01 lease L1: NO BREAK (same inode, just added name)
>>
>> crate(eeefe8d0.vhd.new)
>> -> Entry { path="eeefe8d0.vhd.new", handle=H2, inode=I2 }
>>
>> rename(eeefe8d0.vhd.new, eeefe8d0.vhd)
>> -> SMB2: Replaces “eeefe8d0.vhd” name → points to new inode I2
>> -> Server: old inode I1 now only accessible as “0f11b74e.vhd”
>> -> Server SHOULD send: Lease Break notification to H1 ← KEY!
>>
>> Step 3: Lease break delivery is not reliable
>>
>> strict locking off, level2 oplock
>>
>> Host-01:
>> -> Lease break not received or processed
>> -> H1 is in deferred_closes list (not "active")
>>
>> Result: Stale entry remains:
>> { path=“eeefe8d0.vhd”, handle=H1, inode=I1_OLD }
>>
>> Host-02:
>> -> Open 0f11b74e.vhd in readonly
>>
>> Result:
>> { path="0f11b74e.vhd", inode=I1_NEW }
>>
>> Step 4: Host-01 reopens file
>>
>> Host-01:
>> file open (eeefe8d0.vhd)
>> -> Kernel checks deferred_closes for “eeefe8d0.vhd”
>> -> Found H1! (matched by pathname string)
>> -> REUSES H1 without checking
>> -> close or reconnect, flush buffered writes
>> slient corruption?
>>
>> Signed-off-by: Chunjie Zhu <chunjie.zhu@citrix.com>
>> ---
>> fs/smb/client/fs_context.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c
>> index 0812af001417..4ed33de0a00d 100644
>> --- a/fs/smb/client/fs_context.c
>> +++ b/fs/smb/client/fs_context.c
>> @@ -1300,11 +1300,11 @@ static int smb3_fs_context_parse_param(struct fs_context *fc,
>> ctx->acdirmax = ctx->acregmax = HZ * result.uint_32;
>> break;
>> case Opt_closetimeo:
>> - if (result.uint_32 > SMB3_MAX_DCLOSETIMEO / HZ) {
>> - cifs_errorf(fc, "closetimeo too large\n");
>> + if (result.uint_32 != 0) {
>> + cifs_errorf(fc, "closetimeo must be 0, deferred close is disabled\n");
>> goto cifs_parse_mount_err;
>> }
>> - ctx->closetimeo = HZ * result.uint_32;
>> + ctx->closetimeo = 0;
>> break;
>> case Opt_echo_interval:
>> if (result.uint_32 < SMB_ECHO_INTERVAL_MIN ||
>> @@ -1795,7 +1795,7 @@ int smb3_init_fs_context(struct fs_context *fc)
>>
>> ctx->acregmax = CIFS_DEF_ACTIMEO;
>> ctx->acdirmax = CIFS_DEF_ACTIMEO;
>> - ctx->closetimeo = SMB3_DEF_DCLOSETIMEO;
>> + ctx->closetimeo = 0;
>> ctx->max_cached_dirs = MAX_CACHED_FIDS;
>> /* Most clients set timeout to 0, allows server to use its default */
>> ctx->handle_timeout = 0; /* See MS-SMB2 spec section 2.2.14.2.12 */
>> --
>> 2.52.0
>>
>>
>
>
>--
>Thanks,
>
>Steve
>
prev parent reply other threads:[~2026-06-24 4:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 9:14 [PATCH] fix smb client defer close causes file corruption Chunjie Zhu
2026-06-23 20:39 ` Steve French
2026-06-24 3:44 ` Subject: " Chunjie Zhu
2026-06-24 4:18 ` Enzo Matsumiya
2026-06-24 7:19 ` Subject: Re: [PATCH] fix smb client defer close causes file Chunjie Zhu
2026-06-24 4:19 ` Enzo Matsumiya [this message]
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=ajtavBgQP79ajERS@suse.de \
--to=ematsumiya@suse.de \
--cc=chunjie.zhu@citrix.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsahlber@redhat.com \
--cc=pc@manguebit.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=smfrench@gmail.com \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.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