]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
ksmbd: start file id allocation at 1
authorNamjae Jeon <linkinjeon@kernel.org>
Sun, 21 Jun 2026 10:59:06 +0000 (19:59 +0900)
committerSteve French <stfrench@microsoft.com>
Tue, 23 Jun 2026 01:15:06 +0000 (20:15 -0500)
commit6b375be0b4e1be89e9a817880515311503a19114
tree3a76b57d4afeb82ee31936b02e82a4f82265a248
parentbe939e11c4724d1de3650e8bafd4c3583d9684b2
ksmbd: start file id allocation at 1

ksmbd allocates both the volatile id (per-session file table) and the
persistent id (global file table) with idr_alloc_cyclic() starting at 0.
The first open after the module loads therefore gets volatile id 0 and
persistent id 0, and ksmbd returns an SMB2 FileId of {0, 0} in the create
response.

Clients treat an all-zero FileId as a null handle. smbtorture's
smb2_util_handle_empty() considers {0, 0} empty, so tests that guard the
close with it (e.g. smb2.oplock.statopen1, smb2.lease.statopen*) never
close that first handle. The leaked open keeps the inode's oplock count
non-zero, so a later batch oplock request on the same file is downgraded
to level II and the test fails.

Start the id allocation at 1 (KSMBD_START_FID) so no handle is ever
assigned a {0, 0} FileId, matching the behaviour of other SMB servers.

Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
fs/smb/server/vfs_cache.c
fs/smb/server/vfs_cache.h