]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
smb/client: emulate small EOF-extending mode 0 fallocate ranges
authorHuiwen He <hehuiwen@kylinos.cn>
Fri, 3 Jul 2026 05:32:58 +0000 (13:32 +0800)
committerSteve French <stfrench@microsoft.com>
Mon, 13 Jul 2026 15:37:55 +0000 (10:37 -0500)
commit7a06d3b816d73448b4e38b83d65049f090b7b201
tree807cc0d6c09827d79153531ed8c1fed9105ec392
parent9e4ec3be67af41ab859302d7109b34976efd9258
smb/client: emulate small EOF-extending mode 0 fallocate ranges

When a mode 0 fallocate extends EOF from 1G to 2G + 1M, the client
currently sends SetEOF for 2G + 1M. This can make fallocate return
success without allocating the requested range, or allocate extra
space before that range.

For example, on a fresh file:

        xfs_io -f \
          -c "falloc 0 1G" \
          -c "falloc 2G 1M" \
          -c "truncate 3G" test

The second fallocate should allocate [2G, 2G + 1M), leaving [1G, 2G)
as a hole.

Before this change, the result depended on the server allocation policy.
With Samba "strict allocate = no", SetEOF could return success without
allocating [2G, 2G + 1M). With "strict allocate = yes":

# filefrag -v test
        [0, 1G)             allocated
        [1G, 2G)            allocated unexpectedly
        [2G, 2G + 1M)       allocated

SMB cannot allocate that arbitrary range, so write zeroes to small
EOF-extending ranges instead. Limit this to 1 MiB to bound the
client-side I/O cost.

With "strict allocate = no", the requested range [2G, 2G + 1M) is
allocated by the writes. With "strict allocate = yes":

# filefrag -v test
        [0, 1G)             allocated
        [1G, 2G)            hole
        [2G, 2G + 1M)       allocated

This fixes the small EOF-extending range case exercised by generic/213.

Signed-off-by: Huiwen He <hehuiwen@kylinos.cn>
Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Signed-off-by: Steve French <stfrench@microsoft.com>
fs/smb/client/smb2ops.c