All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.