Re: ksmbd: BUG_ON in locks_release_private() - file_lock destroyed while VFS blocked requests are still attached

> Can you check if an attached patch fixes this issue ?

Yes, it fixes it. Thank you for the quick turnaround.

Tested-by: Kyenghwan Hwang <[email protected]>

Setup: smb3/ksmbd-for-next-next at e7317f3e41 with your patch applied, fs/smb/
built against the 7.2.0-rc7 the branch is based on, freshly booted guest,
CONFIG_KASAN=y, kernel otherwise clean (Tainted: [O]=OOT_MODULE only).

  before (branch as-is):   BUG_ON after ~1.6 s, 142 lock requests
  after  (branch + patch): 11241 lock requests over 181 s, no fault,
                           kernel still Tainted: [O] only

I watched locks_sent climb the whole way (9950 -> 11241 in the last 20 s) rather
than plateauing, since a stalled harness reporting zero faults is how I misled
myself earlier in this thread.


> On ksmbd-for-next-next, to reproduce this issue, the following patch
> needs to be reverted first:
> ("ksmbd: implement the command sequence window")
> I am still analyzing why this patch needs to be reverted to reproduce
> the issue.

That one is my fault, not the kernel's -- the revert is not actually needed. My
reproducer was violating the SMB2 sequence rules and that patch started
enforcing them.

lockfuzz2.py authenticates with impacket and then hand-builds raw SMB2 PDUs, and
kfuzz2.py used to start MessageId at a hardcoded 4096:

self.tid = self.c.connectTree(SHARE)
self.mid = 4096

Once smb2_check_sequence_number() exists, 4096 is outside the connection's
sequence window, so every raw request is rejected with
STATUS_INVALID_PARAMETER -- starting with the CREATE. No file is opened, no lock
is ever sent, and the harness prints

t=5s locks_sent=0 faults=0

which looks exactly like "fixed" but means "the harness did nothing". Reverting
the patch removes the check, the old MessageIds are accepted again, and the bug
reappears -- so the revert looks like it matters when it is really just
restoring my broken client.

The one-line fix on my side is to continue impacket's sequence instead of
inventing one:

self.tid = self.c.connectTree(SHARE)
- self.mid = 4096
+ self.mid = int(s3._Connection['SequenceWindow'])

With that, the reproducer works on ksmbd-for-next-next with the sequence window
patch in place -- that is how I got the 1.6 s / 142 request figure above, and
the test of your patch was run the same way, with nothing reverted.

The other thing that silently zeroes locks_sent is the per-IP connection cap;
the harness churns connections from one address and hits
"Maximum IP connections exceeded (32/32)". I set

[global]
max ip connections = 0

for testing.

So: a non-zero locks_sent is the thing to check before trusting any negative
result from this reproducer. Sorry for the detour -- I should have flagged it
more loudly when I first hit it.

2026년 8월 14일 (금) 오후 2:13, ChenXiaoSong <[email protected]>님이 작성:
>
> Hi Namjae and Kyenghwan,
>
> Namjae's patch can fix the BUG_ON issue.
>
> Tested-by: ChenXiaoSong <[email protected]>
> Reviewed-by: ChenXiaoSong <[email protected]>
>
> On ksmbd-for-next-next, to reproduce this issue, the following patch
> needs to be reverted first:
> ("ksmbd: implement the command sequence window"):
> https://github.com/smfrench/smb3-kernel/commit/15ab73a0feed2aaadde8e7ac3c216f5c0d1d024e
>
> I am still analyzing why this patch needs to be reverted to reproduce
> the issue.
>
> On 8/14/26 12:21, Namjae Jeon wrote:
> > Can you check if an attached patch fixes this issue ?
>
> --
> ChenXiaoSong <[email protected]>
> Chinese Homepage: https://chenxiaosong.com
> English Homepage: https://chenxiaosong.com/en
>