From: Huiwen He <huiwen.he@linux.dev>
To: smfrench@gmail.com, linkinjeon@kernel.org, pc@manguebit.org,
ronniesahlberg@gmail.com, sprasad@microsoft.com, tom@talpey.com,
bharathsm@microsoft.com, senozhatsky@chromium.org,
dhowells@redhat.com, metze@samba.org, chenxiaosong@kylinos.cn
Cc: linux-cifs@vger.kernel.org
Subject: [PATCH 7/7] smb/client: emulate small fallocate ranges at EOF
Date: Tue, 23 Jun 2026 10:46:19 +0800 [thread overview]
Message-ID: <20260623024619.1360127-8-huiwen.he@linux.dev> (raw)
In-Reply-To: <20260623024619.1360127-1-huiwen.he@linux.dev>
From: Huiwen He <hehuiwen@kylinos.cn>
smb3_simple_falloc() now returns -EOPNOTSUPP for mode 0 requests that
start at EOF of a non-empty file because FILE_ALLOCATION_INFORMATION
cannot allocate an arbitrary byte range.
However, one small case can be handled safely: a range that starts exactly
at the current EOF. For example:
xfs_io -f -c "pwrite 0 1m" file
xfs_io -c "falloc 1m 4k" file
This does not create an intervening hole or overwrite existing data. Write
zeroes to the requested range so that it is allocated and EOF is extended
by the write. Limit this zero-write emulation to 1 MiB to keep the cost
bounded.
This allows small EOF-adjacent fallocate requests to succeed. After the
write, update the local file size and refresh i_blocks from the
server-reported AllocationSize. Larger ranges remain unsupported.
Signed-off-by: Huiwen He <hehuiwen@kylinos.cn>
Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
---
fs/smb/client/smb2ops.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
index 4cab652d9696..2922373ab478 100644
--- a/fs/smb/client/smb2ops.c
+++ b/fs/smb/client/smb2ops.c
@@ -3696,6 +3696,43 @@ static long smb3_simple_falloc(struct file *file, struct cifs_tcon *tcon,
if (rc)
goto out;
+ /*
+ * A small range immediately after EOF can be allocated by
+ * writing zeroes without creating an intervening hole.
+ */
+ if (off == old_eof && old_eof != 0) {
+ if (len > 1024 * 1024) {
+ rc = -EOPNOTSUPP;
+ goto out;
+ }
+
+ rc = smb3_simple_fallocate_range(xid, tcon, cfile,
+ off, len);
+ if (rc) {
+ spin_lock(&inode->i_lock);
+ cifsi->time = 0;
+ spin_unlock(&inode->i_lock);
+ goto out;
+ }
+
+ new_eof = off + len;
+ netfs_resize_file(&cifsi->netfs, new_eof, true);
+ cifs_setsize(inode, new_eof);
+
+ qrc = SMB2_query_info(xid, tcon,
+ cfile->fid.persistent_fid,
+ cfile->fid.volatile_fid, &file_inf);
+ spin_lock(&inode->i_lock);
+ if (qrc == 0) {
+ asize = le64_to_cpu(file_inf.AllocationSize);
+ inode->i_blocks = CIFS_INO_BLOCKS(asize);
+ } else {
+ cifsi->time = 0;
+ }
+ spin_unlock(&inode->i_lock);
+ goto out;
+ }
+
/*
* FILE_ALLOCATION_INFORMATION sets the file allocation size. It
* cannot allocate an arbitrary byte range. Use it only when
--
2.43.0
prev parent reply other threads:[~2026-06-23 2:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 2:46 [PATCH 0/7] smb/client: fix fallocate allocation handling Huiwen He
2026-06-23 2:46 ` [PATCH 1/7] smb/client: name the default fallocate mode Huiwen He
2026-06-23 3:50 ` Steve French
2026-06-23 2:46 ` [PATCH 2/7] smb/client: handle smb2_set_sparse() failure in EOF-extending fallocate Huiwen He
2026-06-23 2:46 ` [PATCH 3/7] smb/client: handle smb2_set_sparse() failure in non-extending fallocate Huiwen He
2026-06-23 2:46 ` [PATCH 4/7] smb/client: do not account EOF extension as allocation Huiwen He
2026-06-23 2:46 ` [PATCH 5/7] smb/client: verify allocation after EOF-extending fallocate Huiwen He
2026-06-23 2:46 ` [PATCH 6/7] smb/client: reduce fallocate zero buffer allocation Huiwen He
2026-06-23 2:46 ` Huiwen He [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=20260623024619.1360127-8-huiwen.he@linux.dev \
--to=huiwen.he@linux.dev \
--cc=bharathsm@microsoft.com \
--cc=chenxiaosong@kylinos.cn \
--cc=dhowells@redhat.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=metze@samba.org \
--cc=pc@manguebit.org \
--cc=ronniesahlberg@gmail.com \
--cc=senozhatsky@chromium.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 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.