From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A7EF3148CF for ; Sat, 25 Apr 2026 09:38:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777109917; cv=none; b=a0ZcLpEhTsCnnpCZdUyJXqmj36aqqTrLfmW3dWIqJQeSFHyEjA08jZR6+boU25Chj2p9+UR400EZ9zSb/jRQNT5flcoqg1ZIC4E2+tzc9U7OC1XZ5Fp5A23rEwhqxIqphv2Lz4r6f6X4S2m23vdOpAsbCautVJRGrGueEwcxdHE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777109917; c=relaxed/simple; bh=aNXbkmBeYe7bkZ0ITtRcL7RZi7xiKD8Vu5jVT74b7mY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=fNp1Fy30nRQfWhn4HSSRyBigMu/soditd9WLYhmF5D+IzOlewkYU+PBJgZMwMKmMx+KJimgy19eZcuZHuGWdE0WL+ptNxaBbIzWYKfurxu0edFb0omb4Cljm7Y+/dx64VoculTLCnN5ZlqiTi5ydU6WX4BXAetwEmcFND8DXhmY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=n+Rpb6eW; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="n+Rpb6eW" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2b240d753ceso15609285ad.3 for ; Sat, 25 Apr 2026 02:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777109915; x=1777714715; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=mbVqeApfmb1SRG7yXWeR8Jma0vOyucMXXKmHaiUnCs8=; b=n+Rpb6eWA7oIiMaKqYi9Klmkhr+GVy2K6z0CAkncXStNozW1De3Ie7pTAPj8H1tpvt aFgIk3A6nbF8bnyzi4i7uPujmAeSESIWB80dW2fm7qqmy3GBdE1NxAbTk+5hFY2YYX6y KS4AHQwvM3iq80b01B0zjw3Cp/whCs7t2fUHGKQ//7b2mhQKYAI3qiLp5vE8JDCT27NE FtyiGIxmU8WZZa5wtGg/zocV82qfiVL7RTOco9rf4p/+OK2vwylSNSD65lZBzr0amsGr TnV6O4K3PdYnHCrRSuPpF8yJbU1lf0wB7dMAebxNTVsUxTgXnIwuxNa8BzZ+Ni2n5RYJ jsFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777109915; x=1777714715; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mbVqeApfmb1SRG7yXWeR8Jma0vOyucMXXKmHaiUnCs8=; b=p0vCKI0tZvECOM/EIUtab5SomPzUgTk140rgF84yrRH8V3CXggTx4cgr84/nvybHnB +HGprzatrF/7SuRuOp37VQCpWx8VXBraM/M9DNJ2DB8oeKzDyuhAXm7knta7Nj8UzSe7 4AI9BWEBShEXpCkPqHCbyOKu5+kTsr5cJYM6PdGut6J3Y0g9Ss546iTu3sjPOY8E5zQp uK/ylMMlzOhn4k5tz/bMHL9jwwEgr6kkdr1mKzedrXaeAQLvw+2U3NqNdCo51XZJli5H zmt5RnF3BD4ioXJaimUbVAeXYje5CrntH+fzA663gQ20CKkviFSKgczE1C0M6MpsWxow 4bBw== X-Forwarded-Encrypted: i=1; AFNElJ86xcyE3eOcxrFU0YC4qESM5rOdp/7saoMRH6u1HLazd4GqUILzZ4+Z1hesOdmqmamk4jXLnBcr9qU7jBM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1vOXrdUL4uVCz7SoqpYrkgMGj04zjiBw8N0GUZ3GTCFrZOLs8 17VeRHvLgUHv1oJHw7/phYGb3AHEFRhSVT1lhqJ5b/4+qV1ezi+LJ2Us X-Gm-Gg: AeBDies8g6dSUSw/wxl9scB9gE7owP5jnwH3D9+Nse/mKY+fCbrFkt37QHVaVI9B5Hy YEJFOZgTLEoQ8IJXMvyMVkQP9rK6VrGwLMTFQUV5O+mDsLq9Z1TnBu0wm/zXW95xy+7URYXyNvG 59X6CPRn05EWfw/1qqSU2gK2gH5AVLWCt2Q9pf6ZLnXLXb+4F3wdkTfidCps5qxamxjdBhtMyqj 1gzXjqwKEdovCJ0VhO0MtRQT3ZJPBYxkwM344MjhWoNSj15OsMndQjhCL48XFHcaxOOZLr5qtFe aIN9eS48Iufl1UzHduc3i+4zUE4dV31bKwhzv9RFhfHVW8BjezIVJ2KeiQRhcu5tFAgyJXJL6Hg lfGaoLbjDZxn6tUiNAF+qCvnkiPdDYv7bKi+JY0PEVWdI0n+KjudNyYeFGmRfeKtbJLtwm5kAB0 pxeKbGcDx4IaKdIjWWma7py93N2sBaYQyEH8Jb/A== X-Received: by 2002:a17:903:1b26:b0:2b2:49b9:c063 with SMTP id d9443c01a7336-2b5f9ff619cmr194963735ad.6.1777109915446; Sat, 25 Apr 2026 02:38:35 -0700 (PDT) Received: from ser8.. ([221.156.231.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b606ce9891sm206791725ad.83.2026.04.25.02.38.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Apr 2026 02:38:35 -0700 (PDT) From: DaeMyung Kang To: Namjae Jeon , Steve French Cc: Sergey Senozhatsky , Tom Talpey , Hyunchul Lee , Ronnie Sahlberg , linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, DaeMyung Kang Subject: [PATCH 0/2] ksmbd: fix stop_sessions() iteration and centralize ksmbd_conn release Date: Sat, 25 Apr 2026 18:38:27 +0900 Message-ID: <20260425093829.4004785-1-charsyam@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Two independent fixes around ksmbd connection teardown. Patch 1 ("ksmbd: rewrite stop_sessions() with restartable iteration") fixes a stale-iterator bug in stop_sessions(). The current loop drops conn_list_lock around transport->shutdown() and re-acquires it to continue the same hash_for_each() walk; a concurrent ksmbd_conn_free() in the unlocked window can make the iterator revisit or skip connections. The rewrite pins one connection at a time, marks it via a new conn->stop_called flag, runs shutdown outside the lock, and restarts from the top. The "is the hash drained?" check is moved into the locked walk so it no longer races hash_del() from a handler thread. Patch 1 carries Cc: stable@vger.kernel.org. Teardown wall time, ksmbd.control --shutdown + rmmod ksmbd with N concurrent nosharesock cifs connections (3-run mean): N before after 10 4.93s 5.34s 30 7.34s 7.03s 50 7.25s 7.04s 100 6.98s 6.78s 200 6.77s 6.89s Performance is unchanged; teardown is dominated by the msleep(100) outer retry, not by the iteration. The number of ->shutdown() calls equals the number of live connections on both paths when the race is not artificially widened. Patch 2 ("ksmbd: centralize ksmbd_conn final release to plug transport leak") routes the three bare-kfree final-put sites (ksmbd_conn_r_count_dec, __free_opinfo, session_fd_check) through a new ksmbd_conn_put() that defers the once-per-struct cleanup (ida_destroy, free_transport, kfree) onto a dedicated workqueue. Those sites previously skipped transport cleanup whenever they happened to be the last putter, leaking struct tcp_transport and the iov kvec (TCP) and the embedded async_ida. The workqueue bounce is needed because the centralized release reaches lock_sock_nested() through tcp_close(), which sleeps; __free_opinfo() can be a final putter from an RCU softirq callback (free_opinfo_rcu). A/B leak validation, QEMU/virtme guest with ksmbd server and CIFS client in the same guest, debug kernel (CONFIG_DEBUG_KMEMLEAK + CONFIG_PROVE_LOCKING + CONFIG_DEBUG_ATOMIC_SLEEP + CONFIG_DEBUG_OBJECTS + CONFIG_FAILSLAB): Reproducer per iteration: hold 8 fds open via sleep processes, force-close TCP with `ss -K sport = :445`, kill holders, lazy-umount; 10 iterations, then ksmbd shutdown + kmemleak scan. Pre-patch is HEAD with only patch 1 of this series applied: state conn_alloc conn_free tcp_free opi_rcu kmemleak ---------- ---------- --------- -------- ------- -------- pre-patch 20 20 10 160 7 with patch 20 20 20 160 0 Pre-patch conn_free=20 with tcp_free=10 directly demonstrates the bare-kfree paths skipping transport cleanup; kmemleak reports 7 unreferenced struct tcp_transport / t->iov objects. With patch 2 tcp_free matches conn_free at 20/20 and kmemleak is clean across two independent post-patch runs. opi_rcu=160 confirms the RCU opinfo release path that motivates the fix is exercised. Patch 2 also addresses two adjacent issues exposed by the new debugging context: * __close_file_table_ids() refactor. session_fd_check() already sleeps in kstrdup(GFP_KERNEL) and down_write(m_lock) before this patch, but the existing code calls it under write_lock(&ft->lock) (an rwlock_t). Refactor so skip() runs outside ft->lock with a transient reference on fp; idr_remove(), fp->volatile_id clear and the m_fp_list unlink happen unconditionally so a deferred final putter (atomic_sub_and_test(2) returning false) cannot be left to do them via __ksmbd_remove_fd() with a stale volatile_id. Validated on an additional debug kernel built with CONFIG_DEBUG_LIST + CONFIG_DEBUG_OBJECTS_WORK using a same-session two-tcon storm: one tcon drives an open/write storm while the other tcon repeats 50 tree disconnects on the same session. Trace counts: 52 __close_file_table_ids invocations, 4793 __ksmbd_close_fd, 30337 __put_fd_final, 9578 ksmbd_conn_put, 1 __ksmbd_conn_release_work. No list-corruption, work_struct ODEBUG, sleep-in-atomic, lockdep or kmemleak reports observed. This stress validates the file-table/id/list rewrite under DEBUG_LIST/DEBUG_OBJECTS_WORK, not the transport leak (which the A/B above already covered). * fp owns a strong reference on fp->conn. fp used to hold a borrowed pointer to its connection, leaving a window where the conn could be freed while a still-live fp held a stale fp->conn. Make fp own a refcount on fp->conn from ksmbd_open_fd() / ksmbd_reopen_durable_fd() until __ksmbd_close_fd() or session_fd_check(). ksmbd_reopen_durable_fd() is also reordered so fp->conn / fp->tcon are set before __open_id() publishes fp into the session's file table, so a concurrent teardown cannot observe a valid volatile_id with fp->conn == NULL. The two patches are independent. Either can be reviewed, applied, or reverted without pulling the other. Patch 2 references patch 1 only to explain why stop_sessions() is left on its open-coded local cleanup and not converted to ksmbd_conn_put() in this series; if patch 2 is applied alone, stop_sessions() retains its bare-kfree leak that patch 1 separately addresses. Based on ksmbd-for-next-next. DaeMyung Kang (2): ksmbd: rewrite stop_sessions() with restartable iteration ksmbd: centralize ksmbd_conn final release to plug transport leak fs/smb/server/connection.c | 120 ++++++++++++++++++----- fs/smb/server/connection.h | 6 ++ fs/smb/server/oplock.c | 4 +- fs/smb/server/server.c | 12 +++ fs/smb/server/vfs_cache.c | 189 ++++++++++++++++++++++++++++++++----- 5 files changed, 285 insertions(+), 46 deletions(-) -- 2.43.0