From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (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 B3DF82D2397 for ; Tue, 30 Jun 2026 07:19:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.177 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782804000; cv=pass; b=qXpDzV0dwLXYCQeFz32Q+5XD6UHhpoyn2FNx5IN/6bztp53vGyIabF/REP39T/frZ2oDvd5xShL9qlOEhMbdcNbyfyeHaUO/ptJhtF97YXINuw/0KoKGEbzE/zLYL2PeDYq4HTLclzLVgJ+/nHV/y1qh7KJCAncjPrnfmE5hFKQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782804000; c=relaxed/simple; bh=F28JSHUvtIiMJrHZex2q5cijigT1XfCkWVMp0pOXSGE=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=obQQ2Tg1aX0RpiRg4mXdXzLQnXnqa0xVT68Fd0XSExKUONPVKWy3TgW8cU/7EHu7SE0kqe8JYNF9mv5f53bwgKu9B25Sa4HK3HvVEKnkwfGzYNVa1LXTPZaC9XjwZjtfhhFEPCC3O4aaH5obtpxs3krrkdQAONITzXSqXoDP/II= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=WO4vMDUR; arc=pass smtp.client-ip=209.85.160.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WO4vMDUR" Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-51c05dcdf49so17753981cf.0 for ; Tue, 30 Jun 2026 00:19:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782803998; cv=none; d=google.com; s=arc-20260327; b=GnH1yiO6LrYaW3Oc3GWHBTJCKDzBQghaij2twSQdf8Dlxl6PNJ2/g9bMTL+kSD9xOu XZ5OSgdyM88WD0tY4hD/I5J6j/XME9DhiPec4ZEsH89IBbhRC4WHJbLrhrUyNGaA+qz0 2ZRxCucBOMbytc1j627GjTI0sjPKlfS8o7e5lwT1xtmPBdKgHlmYJihBZEtIxEo66p7b oBJS2JUdu53vhr1toI9qawAtniJ2G8fuPsGJnEzLuS5tbEDP+C+WqMZmE2VWghGXpz40 /6TgzRPg0ArVaJb5/CIq7o2CBf/LEDvRFYbRPCOYY5qjxLHjPTcbPxKrFU+HopdhT5d8 9xsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=F28JSHUvtIiMJrHZex2q5cijigT1XfCkWVMp0pOXSGE=; fh=Za72xsC9OJI4bcmdLPbojVlnls2wiN4CYPe6vqch1hc=; b=Q1MmqFbxOgtINd7luqskl0QE6Qtpfw90X2gSOAp6HHNOolcfAsxGOlfEzfIekN/SRw JC7OVD7mPa9hvh56HAPTk6FB5uX/EC6IaKit2IFNVHPWts7kkVLdxk9InvLCWb+Iphxv rnOzzOZ8YzRvHQp7PmwF2VSWG7tz865U3/TKEL07u1uhcmqvArKby8M9DN0TqFnbKYsw 19a2utF/N71zvDMRoTUCgxDIiA7pfoK2kg85+KT/pUa/ZOS/L1C4dVmQNuc9Y14LhIff 3OJ8/BZugEHFcu0jFpzfkyk/B2AlMLkheeORRTth9AP+dWAho8zAb60xT6c//ojvkitI HxeA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782803998; x=1783408798; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F28JSHUvtIiMJrHZex2q5cijigT1XfCkWVMp0pOXSGE=; b=WO4vMDUR22FABgTX2mO9ipdk0/9/sbrG37TxSEaIaZpX/ZQC+Z5Fz7JSlYOxe/2GYu dx10Icvn/NyG1qoOi/JPy84liz9ZzASKW6wEopIIIZ+DFDBsPtYizq+YAbfif+pk14Xe xv3loAloIGDax2iOmcgzg1EX4tdRk9kgoDi5Z7guJ9HpeZLwB4MKSp1HjLv+XIBdcpk7 JWqNLlvMCxwalFkHfKUYn6VGKo2U+1EkOlu/oybAsIeQ3K1P2dxzivbQtqCUwzjbECLJ VRz7JU2wqU/QZv6cfLYKVOuyeCZQzNj2mZXmhIZrMMzV4V+Hn8a89pVzVGaw0mCzhjTw j5aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782803998; x=1783408798; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=F28JSHUvtIiMJrHZex2q5cijigT1XfCkWVMp0pOXSGE=; b=Gyo406CYKhEsZd4CvaGjCKrFuJXkgb9TcY1UeSGIePX5TdIV0Nqu++RLfwcjrlQcVV N43VTVrdq9gQ7QXqUte8au+1zBAG0m4T5Wuzbl6ZFkzRzVxnqpbPHWAr9AC80seEg2Kr c4zrn0Hah7FvnN7b7xZXpfi7kg/doAUted+RgLv7zy0IJAipj3KynUkXdFgo+5+wNpC/ gALjeQgHGFPs1QsGavja/ML82XI2bUchZb9N5l5+bGv6uXim4oqTMWrzemdXCiT7aOEO 3uMCj4P/h0/qnuwKcbexgUO79SMr71jSOfaRNEeiMpVBA5CyiJbJoYiJg0Mu071H9Ui5 bPaA== X-Forwarded-Encrypted: i=1; AFNElJ8rVjZR7et56N/lbtc3e0SomDrgcs7kOuSMvgYihFLyXzXTYulKagM+N1ww0RbI+Hh5fFF//yotNgeVVjw=@vger.kernel.org X-Gm-Message-State: AOJu0YwumJ6nqx6whqs2UkibHnpOXxHyk2sjDgGlF+9hS+y8ruhxp1iY PtoceDlG7ojWhIjbiTWcr+uhpAfbMrpmBo+2TaMd4g7Bfn+X4Kn4Yrh5TlNbiee5xSOh/VqDNMR VU67n8x6EVCJ5jtzaOzdOwYdLWf8LCIsjTzkLH13U X-Gm-Gg: AfdE7clj2yS2tM1R+DMhl1WzYdzST1L9hKRe829954zl4ORz7rh+h/nSKO9EIKFawS2 ZtWvDOV6784/eZOEyn7cU0Frf+TF83Fbn/QEV8YTV0+4TB46xyKN0GyZJyyfY0lrUF/IdRa0LvS Hxnnel4KLoVSY8d3DWKhuLAey6R3hqW5AdOG9SNMFNqRFa+1jxB1ZCMXZhVquVDoc98A2r1a2tS FM0hnm6dtCBNBaFH5wUqdE2ACdyUkwI2uhoCLU0Al4LO0iTIDvL0QhFOGXeoQJkdddp8/cr2WNq 4I8ztb0lDZyCu14zrss7rONbk7D6HiXjh5hkpAgTzKkfPW5qrLdir6mWP/hlhv/eP/bpm3dz7Mg XhsiR97Fl X-Received: by 2002:a05:622a:1304:b0:51c:981:94a6 with SMTP id d75a77b69052e-51c107b21b8mr32148201cf.23.1782803997273; Tue, 30 Jun 2026 00:19:57 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260629052854.252-1-hdanton@sina.com> In-Reply-To: <20260629052854.252-1-hdanton@sina.com> From: Eric Dumazet Date: Tue, 30 Jun 2026 00:19:45 -0700 X-Gm-Features: AVVi8Cefl2XQm68lhL58TMM5XfBLIzHlOMqm7XlLDyUcPbD7Erz5hlsvmGjm4H0 Message-ID: Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock To: Hillf Danton Cc: Deepanshu Kartikey , linux-block@vger.kernel.org, nbd@other.debian.org, linux-kernel@vger.kernel.org, syzbot+6b85d1e39a5b8ed9a954@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 28, 2026 at 10:29=E2=80=AFPM Hillf Danton wr= ote: > > On Mon, 22 Jun 2026 17:21:53 -0700 Eric Dumazet wrote: > >On Mon, Jun 22, 2026 at 5:07=E2=80=AFPM Hillf Danton = wrote: > >> On Mon, 22 Jun 2026 01:18:10 -0700 Eric Dumazet wrote: > >> >On Sun, Jun 21, 2026 at 6:43=E2=80=AFPM Hillf Danton wrote: > >> >> On Mon, 22 Jun 2026 05:22:55 +0530 Deepanshu Kartikey wrote: > >> >> > nbd_reclassify_socket() warns via WARN_ON_ONCE() if the socket lo= ck is > >> >> > held at the point of reclassification. That assertion was copied = from > >> >> > nvme-tcp, where the socket is created internally by the kernel > >> >> > (sock_create_kern()) and is never visible to user space, so the l= ock > >> >> > is guaranteed to be free. > >> >> > > >> >> > NBD is different: the socket is looked up from a user-supplied fd= in > >> >> > nbd_get_socket(), and user space retains that fd. A concurrent sy= scall > >> >> > on the same socket (or softirq processing taking bh_lock_sock() o= n a > >> >> > connected TCP socket) can legitimately hold the lock at the insta= nt > >> >> > NBD reclassifies it. sock_allow_reclassification() then returns f= alse > >> >> > and the WARN_ON_ONCE() fires, which turns into a crash under > >> >> > panic_on_warn. This is reachable by simply racing NBD_CMD_CONNECT > >> >> > against socket activity on the same fd, as reported by syzbot. > >> >> > > >> >> Given the syzbot report, if you are right (I suspect) then Eric del= ivered > >> >> another half-baked croissant, and feel free to cut it off instead t= o make > >> >> room for correct fix. > >> > > >> > Nobody (including you) caught this.difference between nbd and other > >> > sock_allow_reclassification() callers. > >> > > >> Nope, actually it raises the question -- does the deadlock still remai= n > >> after your fix without the lock key you added applied? > > > >LOCKDEP might have a false positive, but it will be much much harder to = trigger. > > > >I had about 50 syzbot duplicates (that I did not release) before d532cdd= b6c60 > > ("nbd: Reclassify sockets to avoid lockdep circular dependency"). > > > >> > >> > What was the "correct fix" you envisioned exactly? > >> > > >> Frankly I had no evidence against your fix a couple days back, but now= I > >> see your lock key approach fails to take off. And the correct fix is t= o > >> erase the incorrect locking order ffa1e7ada456 tries to catch, more > >> difficult than you thought so far. > > > >Which incorrect locking order are you referring to? This is a LOCKDEP > >false positive. > > > For archive purpose, syzbot report [1] where udp was not invovled defies > what is fixed in d532cddb6c60 ("nbd: Reclassify sockets to avoid lockdep > circular dependency") -- "Since the UDP socket and the NBD TCP/TLS socket > are different, this is a false positive." > > > [1] Subject: [syzbot] [net?] possible deadlock in inet_shutdown (3) > https://lore.kernel.org/lkml/69c37e6a.a70a0220.234938.0045.GAE@google.com= / Why don't you send a patch if you think one is needed?