[{"id":3679060,"web_url":"http://patchwork.ozlabs.org/comment/3679060/","msgid":"","list_archive_url":null,"date":"2026-04-19T07:29:37","subject":"Re: [PATCH 2/2] ksmbd: reset rcount per connection in\n ksmbd_conn_wait_idle_sess_id()","submitter":{"id":79386,"url":"http://patchwork.ozlabs.org/api/people/79386/","name":"Namjae Jeon","email":"linkinjeon@kernel.org"},"content":"On Sun, Apr 19, 2026 at 2:30 AM DaeMyung Kang wrote:\n>\n> rcount is intended to be connection-specific: 2 for curr_conn, 1 for\n> every other connection sharing the same session. However, it is\n> initialised only once before the hash iteration and is never reset.\n> After the loop visits curr_conn, later sibling connections are also\n> checked against rcount == 2, so a sibling with req_running == 1 is\n> incorrectly treated as idle. This makes the outcome depend on the\n> hash iteration order: whether a given sibling is checked against the\n> loose (< 2) or the strict (< 1) threshold is decided by whether it\n> happens to be visited before or after curr_conn.\n>\n> The function's contract is \"wait until every connection sharing this\n> session is idle\" so that destroy_previous_session() can safely tear\n> the session down. The latched rcount violates that contract and\n> reopens the teardown race window the wait logic was meant to close:\n> destroy_previous_session() may proceed before sibling channels have\n> actually quiesced, overlapping session teardown with in-flight work\n> on those connections.\n>\n> Recompute rcount inside the loop so each connection is compared\n> against its own threshold regardless of iteration order.\n>\n> This is a code-inspection fix for an iteration-order-dependent logic\n> error; a targeted reproducer would require SMB3 multichannel with\n> in-flight work on a sibling channel landing after curr_conn in hash\n> order, which is not something that can be triggered reliably.\n>\n> Fixes: 76e98a158b20 (\"ksmbd: fix race condition between destroy_previous_session() and smb2 operations()\")\n> Cc: stable@vger.kernel.org\n> Signed-off-by: DaeMyung Kang \nApplied it to #ksmbd-for-next-next.\nThanks!","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-cifs@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=nlkF91Sc;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-cifs+bounces-10910-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"nlkF91Sc\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fz0d43B3mz1yGs\n\tfor ; Sun, 19 Apr 2026 17:30:00 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 5F1D73008A6B\n\tfor ; Sun, 19 Apr 2026 07:29:53 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 3F873378818;\n\tSun, 19 Apr 2026 07:29:52 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 19AD73783D4\n\tfor ; Sun, 19 Apr 2026 07:29:51 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id B40F0C2BCB8\n\tfor ; Sun, 19 Apr 2026 07:29:51 +0000 (UTC)","by mail-ed1-f47.google.com with SMTP id\n 4fb4d7f45d1cf-672c23aa064so3718008a12.2\n for ;\n Sun, 19 Apr 2026 00:29:51 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776583792; cv=none;\n b=Bg8rsXjN8n3GCao5yIMLctaYbuhrzEvAn74SFR35rdRUGg4t86eAmQFBFFI/6wzrf38+64QCIp7V8BJrapIdPkmXTs+l1rSNUkKeZH9RW597KUCt99Vp1ze4KfO64siRrw5LxauqgmudP7xP+Zxly/cz4X1dTuqOAhSJ/O82F00=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776583792; c=relaxed/simple;\n\tbh=QJqUE+KIWv01jPr0qaOhAYIMdk3vkM2VjM9uMykgIa8=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=Pd7lFPI+57RYo2KQS9DuOfXV3PUFR01MbAf+0+7A9hbehBmJdzeTLkB2w8Y7Cv0Dh4IMrmLKZFoVQ3av+WWKgXuJVxaNKyuiujg2Hp53cTfdlHAJAWq2Mn/nmNM0Tzv0sZSi+MRxQFv9UFNWfJy5hG8r2hD1riwIpLrvqo0dh5g=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=nlkF91Sc; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776583791;\n\tbh=QJqUE+KIWv01jPr0qaOhAYIMdk3vkM2VjM9uMykgIa8=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=nlkF91ScFrhpJeWmo1aO+q9hRzmgOcNKxtcqnRMBVcf9SjhY9uEGOy0rXV/+addoR\n\t 39Zn9iZBa0yim4uCArlyeqAtJIoKPYE0b5MWFHpVrf68eDBztMYO7Jf7/ZMjFQSTF1\n\t FUfB1Zr+NGRCkq54I/unG5GC2ACKao4OFLTVSOgzLtmrIlbo6OLhjPRPd14N7HNdnf\n\t Eag/SWD1qUrqi7ck1AzlIhiwxMv75FB/zbo/gCucQBggWMxQ7njYlD2nCsUo4K9Mfy\n\t 7AXCir9HquZyqrmaUaXwSQtC17FO3Q6qAZkkLG64i4klgiPyIEkM/ibh3YSztGNyEB\n\t 9mt7dEfYqFcCg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+HjQvwtaFKtposhuVLDw0iqvrDIeqavHR4uUw3WvAM3kQ4zi4JtYlh46pY9mmDYJU6lAIK9WOp1cYp@vger.kernel.org","X-Gm-Message-State":"AOJu0YwcA00cBRHgZpqnjq2IEVAsbyC75qJY9FWdPMLShIHQLF9t/GRk\n\tgPEiQ7KnqIUKzqzEu1z0GznWXcEI39lCFCDRnwOyGMj/819x47o6ftDjr/Xa60WyqeW7iMJDVNK\n\tUU+uVaAr9DEqfjD9QololMxvCPTTRCcg=","X-Received":"by 2002:a05:6402:a54e:10b0:669:cc03:334a with SMTP id\n 4fb4d7f45d1cf-672bfd9db0dmr3075102a12.11.1776583790183; Sun, 19 Apr 2026\n 00:29:50 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-cifs@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260418172844.1333378-1-charsyam@gmail.com>\n <20260418172844.1333378-3-charsyam@gmail.com>","In-Reply-To":"<20260418172844.1333378-3-charsyam@gmail.com>","From":"Namjae Jeon ","Date":"Sun, 19 Apr 2026 16:29:37 +0900","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzAOKLjcpFyO0NiqvNftv3mmS9SxvjLG3WX0f-Iq4zWubKruu_tv2He3XbY","Message-ID":"\n ","Subject":"Re: [PATCH 2/2] ksmbd: reset rcount per connection in\n ksmbd_conn_wait_idle_sess_id()","To":"DaeMyung Kang ","Cc":"smfrench@gmail.com, senozhatsky@chromium.org, tom@talpey.com,\n\tlinux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tstable@vger.kernel.org, Henrique Carvalho ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}}]