From: DaeMyung Kang <charsyam@gmail.com>
To: linkinjeon@kernel.org
Cc: senozhatsky@chromium.org, tom@talpey.com,
chenxiaosong@chenxiaosong.com, linux-cifs@vger.kernel.org,
linux-kernel@vger.kernel.org, DaeMyung Kang <charsyam@gmail.com>
Subject: [PATCH 0/2] ksmbd: fix SetAllocation EOF and rounding
Date: Sat, 17 Oct 2026 12:40:49 +0900 [thread overview]
Message-ID: <20261017034051.72932-1-charsyam@gmail.com> (raw)
In-Reply-To: <CAKYAXd_50E7cH51hxKi9xWfE3Hjyj0PhwccgsuGX416pEJVs8A@mail.gmail.com>
In response to Namjae's review of my earlier SetAllocation patch, this
series separates two fixes. Patch 1/2 prevents the existing cleanup
branch from extending EOF on disk and then restoring only the in-memory
size. It carries Fixes and Cc: stable. Patch 2/2 rounds the request to
f_bsize, the allocation unit ksmbd advertises in FS_SIZE_INFORMATION,
instead of 512 bytes.
The other review point, reserving the requested range when shrinking,
remains open. I tried fallocate before truncate, but the decision to
shrink uses an EOF value read before vfs_truncate() takes inode_lock.
The existing block-count branch already has this race; extending
truncate to additional sparse-file cases would expose it more widely.
If another client truncates and writes in that interval, our truncate
can extend the file again with zeros. I reproduced this with an
injected delay in QEMU. Rechecking EOF after fallocate narrows the
window but does not close it.
A VFS operation that checks EOF and truncates under the same inode_lock
without extending the file may be needed. I plan to discuss the
reservation fix separately with linux-fsdevel and would welcome your
thoughts on that approach.
DaeMyung Kang (2):
ksmbd: avoid restoring only in-memory EOF after allocation change
ksmbd: round SetAllocation to the advertised allocation unit
fs/smb/server/smb2pdu.c | 48 ++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 25 deletions(-)
base-commit: bf3465919b0337dfef8798da01469145887c4ef5
--
2.43.0
next prev parent reply other threads:[~2026-10-17 3:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 11:52 [PATCH] ksmbd: truncate files before allocating space below EOF DaeMyung Kang
2026-10-13 22:17 ` Namjae Jeon
2026-10-17 3:40 ` DaeMyung Kang [this message]
2026-10-17 3:40 ` [PATCH 1/2] ksmbd: avoid restoring only in-memory EOF after allocation change DaeMyung Kang
2026-10-17 3:40 ` [PATCH 2/2] ksmbd: round SetAllocation to the advertised allocation unit DaeMyung Kang
2026-10-19 23:47 ` [PATCH 0/2] ksmbd: fix SetAllocation EOF and rounding Namjae Jeon
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=20261017034051.72932-1-charsyam@gmail.com \
--to=charsyam@gmail.com \
--cc=chenxiaosong@chenxiaosong.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=senozhatsky@chromium.org \
--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.