From nobody Sun May 24 20:33:25 2026 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 D431F2236F0 for ; Fri, 22 May 2026 22:00:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779487233; cv=none; b=Q+1glG6oP/Q4KlUFB7z8kNHRCgDBG7OS/tBePDugj7Wa77XTWl0/7241RTR4wAadzGKFR+rwfwX7fsaaFBi6FBy1Wr5sZiePrMmz5+GPPdL8Xlc85C+8NrD04XBb/Falrj6vcarGin8OLKuNN9Gzn8OPmNLKC0YSBGAzWHo370E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779487233; c=relaxed/simple; bh=1x9ywyVrh7uZCSRgauiK8pD0FtPRQ68pgvijqVPekKY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=TNkPc3BHMM3G5OpMQmi/z8mwJqRW9YCxpR7TdjrEXeqzEvn0gRSLJNBFl/XLsQySBge85wOc51Ro8RIwiy4j6zaoIgjBkSRJKvXvjDMkNC2nIQ2Hexpd8KBFH3/qZKJ6N1kelNdk5uJmEKLaSZisepAAZnUO+MesjoKJj0F5m9Y= 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=MHAZH3zR; arc=none smtp.client-ip=209.85.222.49 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="MHAZH3zR" Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-95ce0cf2d4bso4693171241.0 for ; Fri, 22 May 2026 15:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779487230; x=1780092030; 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=3ftv7qUW3GQKarcWelUk5mazFgUp2QWWE6TkRhUcbZA=; b=MHAZH3zRcDjTpCkyf2EmUqDzMliKJldKnMxbn5lyrc6SB3SAa9AM77p7fJSuRhQwho 3QTYmXsBIHp+oitDwK9cd2VyxTXkE+KnFQBM2AoATME+355BxLtQ89ApNYz7xSKk2BZN LeGJxW0qmoMRTqs5fN6SjDcQIB2c14kqvotuVrL1Zkw88rw1yz0D4O3P6MJqs3YkkzFR 36IumhWRul+hclgHfqzdlJY/5CdMldxK8iGZrD59lVNSxLNNbSIlTLdqE8uE05D9jHe5 ev/XMsxlm4Gi1R0IlxXPo+pNYfvWWLt6aZGCRmBs5MgMF5HvDUAn4Y3sLsz1yhO5ALGa pLBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779487230; x=1780092030; 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=3ftv7qUW3GQKarcWelUk5mazFgUp2QWWE6TkRhUcbZA=; b=bzPDrl4QzE4yqXZQf5ObHbZQAM2fs25F5yxLKY1/B1uJftPoB3XTMWm2jfd2z+ZqKV mGZ5hUoBLFy3GcFt1dd9r0FgQMMLW/B5Ry/fWWfa+RiL23Wh57paSBgf2M14ncwjXwqM gm/E4o+pTRGD7ptot+Ai4cXOfBecQFlricUXK5gOROCTeooWBqH6C7S2HBHCS4FjFq+9 Q+x4a/8+OoPJk2zZxyJXI+vBz9Lx5lRLrF84q8RRb4tIl6k5gFjulRxWd4Ct7OgXfeCb uKVtNtczTBTrBuOki8iC2CBq8zG57V8cdN5QDyaUjH5gua0VVxuHEqmnj3dRr9vlF8Ey o8cQ== X-Forwarded-Encrypted: i=1; AFNElJ9S2ITExB0QVG0ZSlQkKEyiOC2OazdfmTQNZFy9jv5HrgE7njJl/9MCU7cqaTBG9Yf9Ebia3LwkJKEwai8=@vger.kernel.org X-Gm-Message-State: AOJu0YxhmlbBJTAAzA1K3ewfrkOKErPpzAD+FDKK2LHudkByxF6ZE5d7 VnZ89eBBCNnFTlInSoaOe+5xTMVnOBOFrxibYje215hp2SRuZuBf+jxfLqD1c/1SLSE= X-Gm-Gg: Acq92OEJf0WME7hRkmjZk68XHzkt7s3OBtCHIYJKeFhxhFZ/pDQCm2cK/iy7kdbDOxE 6cXEbsPBTGJ/Fl2Xb0epEx/TBsKteNQQRAG00jdbwGh9ls72hTu0gxO5U2tvAH60O3LdVg+CV9a ZRvg/ffcfgDrOrZQl4mdQcIes9S9JQDPne7jCNXUBZCYNrh+/KgSloFdungqaXZYQLN6WUVJ6rd hrohL/YMM7aMx5xDEP7MZBimc+2SBUXcnZzAr3rDdK6ArCTexYWYglvj/HYhQS6uote6oD0F6Im YaBphKt/bzhvGPMHJKGic2Swr35olsyoBuDHEWe6ID48NAYKktIjZrRYtRs5eWrrNrZCZYpfZTx v8Nzkv6q+pxLk8bFQo4mqNnCoxkAvuAftleQ3vgdUA8QeQdeZWbgxZGA4KdOH00/zlQ8oNMXyUA mDrsCeEyrhN/iUAjOe3pDq0on1I6HIqZ6q1hsH5rVJabKUq/Ec8XId X-Received: by 2002:a05:6102:304d:b0:631:ba82:e80 with SMTP id ada2fe7eead31-67c8e2bf3a1mr2339524137.11.1779487230323; Fri, 22 May 2026 15:00:30 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-67fd8851f5bsm2957284137.3.2026.05.22.15.00.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 15:00:29 -0700 (PDT) From: Chao Shi To: Jens Axboe Cc: Christoph Hellwig , Christian Brauner , Josef Bacik , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Shi , Sungwoo Kim , Dave Tian , Weidong Zhu Subject: [PATCH] block: skip sync_blockdev() on surprise removal in bdev_mark_dead() Date: Fri, 22 May 2026 18:00:25 -0400 Message-ID: <20260522220025.1770388-1-coshi036@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: quoted-printable Content-Type: text/plain; charset="utf-8" bdev_mark_dead()'s @surprise =3D=3D true means the device is already gone. The filesystem callback fs_bdev_mark_dead() honours this and skips sync_filesystem(), but the bare block device path (no ->mark_dead op) lost its !surprise guard when the holder ->mark_dead callback was wired up (see Fixes), and now calls sync_blockdev() unconditionally, which can hang forever waiting on writeback that can no longer complete. syzkaller hit this via nvme_reset_work()'s "I/O queues lost" path: nvme_mark_namespaces_dead() -> blk_mark_disk_dead() -> bdev_mark_dead(bdev, true) -> sync_blockdev() blocks in folio_wait_writeback(), wedging the reset worker and every task waiting on it. Skip the sync on surprise removal, matching fs_bdev_mark_dead(); invalidate_bdev() still runs. Orderly removal (surprise =3D=3D false) is unchanged. Fixes: d8530de5a6e8 ("block: call into the file system for bdev_mark_dead") Found by FuzzNvme(Syzkaller with FEMU fuzzing framework). Acked-by: Sungwoo Kim Acked-by: Dave Tian Acked-by: Weidong Zhu Signed-off-by: Chao Shi --- block/bdev.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/block/bdev.c b/block/bdev.c index b8fbb9576110..7fc3f5ba22a3 100644 --- a/block/bdev.c +++ b/block/bdev.c @@ -1259,7 +1259,13 @@ void bdev_mark_dead(struct block_device *bdev, bool = surprise) bdev->bd_holder_ops->mark_dead(bdev, surprise); else { mutex_unlock(&bdev->bd_holder_lock); - sync_blockdev(bdev); + /* + * On surprise removal the device is already gone; syncing is + * futile and can hang forever waiting on I/O that will never + * complete. Match fs_bdev_mark_dead(), which also skips it. + */ + if (!surprise) + sync_blockdev(bdev); } =20 invalidate_bdev(bdev); --=20 2.43.0