Re: [PATCH 2/2] ksmbd: reset rcount per connection in ksmbd_conn_wait_idle_sess_id()

[Namjae Jeon]

On Sun, Apr 19, 2026 at 2:30 AM DaeMyung Kang <charsyam@xxxxxxxxx> wrote:
>
> rcount is intended to be connection-specific: 2 for curr_conn, 1 for
> every other connection sharing the same session.  However, it is
> initialised only once before the hash iteration and is never reset.
> After the loop visits curr_conn, later sibling connections are also
> checked against rcount == 2, so a sibling with req_running == 1 is
> incorrectly treated as idle.  This makes the outcome depend on the
> hash iteration order: whether a given sibling is checked against the
> loose (< 2) or the strict (< 1) threshold is decided by whether it
> happens to be visited before or after curr_conn.
>
> The function's contract is "wait until every connection sharing this
> session is idle" so that destroy_previous_session() can safely tear
> the session down.  The latched rcount violates that contract and
> reopens the teardown race window the wait logic was meant to close:
> destroy_previous_session() may proceed before sibling channels have
> actually quiesced, overlapping session teardown with in-flight work
> on those connections.
>
> Recompute rcount inside the loop so each connection is compared
> against its own threshold regardless of iteration order.
>
> This is a code-inspection fix for an iteration-order-dependent logic
> error; a targeted reproducer would require SMB3 multichannel with
> in-flight work on a sibling channel landing after curr_conn in hash
> order, which is not something that can be triggered reliably.
>
> Fixes: 76e98a158b20 ("ksmbd: fix race condition between destroy_previous_session() and smb2 operations()")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: DaeMyung Kang <charsyam@xxxxxxxxx>
Applied it to #ksmbd-for-next-next.
Thanks!