From patchwork Tue Nov 12 12:58:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 13872196 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18CF170831 for ; Tue, 12 Nov 2024 12:59:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731416352; cv=none; b=r5PkjXiXAAUh9fT4wbZX6SFvQkB31rQmqwZEl8PLkgO9+NprTPp6Ra2ajfQzMvwGp9ynaxFJYPUAORIb698PX1BDmUQgPUQmob3lUS2skCQVg6Q7yeYlgNt3e9JmSsXM/+1e4D8JTNOFOTbRSwgm9Cp43ordWPoPMmktPEgkAKc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731416352; c=relaxed/simple; bh=1vbxq5fT9J6QY/YtVQ9Yjav2Qr4N+rl9SPUs0pVnCC8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=AW4pyqWsrb3/A2+36Fm/5lhsDaazBNC/tMXMdSdB2RJODS8v1K+7K/u5ZlsPtABxdHMiMcydpge2oj7MZJdqp9MhJFZ317mzxHBCaxDKQCN7ow0yHm6XWn+4w8Rdto2yK2a6K9Z7rXDQlB1H4JypeF3buJuTlwaKefux+X6QxMw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Nu6Zo9qX; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Nu6Zo9qX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731416350; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qEpwcMR888T/fdKl57hnA0eznf4rvVS3n72MHv4ya/g=; b=Nu6Zo9qX4ePTLzOaxKWdC7TwmB75Okz70kgQpi88daKYPtQ84xC71kQoJHBJJQ9XiHUs6Y DG5rSAF9YqS/Nuo6lFMlCTzNfy6W5URfDlanSv+6jNPLYI+4ZlnULBn7V0K9Yk6WlB52dv oRTzbj2UHTWhk6xeGWt7z1DTDF9L+EI= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-178-z4sXu5h1O8Ov2pYmR0jq4g-1; Tue, 12 Nov 2024 07:59:07 -0500 X-MC-Unique: z4sXu5h1O8Ov2pYmR0jq4g-1 X-Mimecast-MFC-AGG-ID: z4sXu5h1O8Ov2pYmR0jq4g Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1A69B1955BEF; Tue, 12 Nov 2024 12:59:05 +0000 (UTC) Received: from localhost (unknown [10.72.116.29]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4366F1956086; Tue, 12 Nov 2024 12:59:02 +0000 (UTC) From: Ming Lei To: Jens Axboe , linux-block@vger.kernel.org Cc: Ming Lei , Yi Sun , "Michael S. Tsirkin" , Jason Wang , Stefan Hajnoczi , virtualization@lists.linux.dev, Marek Szyprowski Subject: [PATCH] virtio-blk: don't keep queue frozen during system suspend Date: Tue, 12 Nov 2024 20:58:21 +0800 Message-ID: <20241112125821.1475793-1-ming.lei@redhat.com> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending. block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze(). [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/ Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend. Cc: Yi Sun Cc: Michael S. Tsirkin Cc: Jason Wang Cc: Stefan Hajnoczi Cc: virtualization@lists.linux.dev Reported-by: Marek Szyprowski Signed-off-by: Ming Lei --- drivers/block/virtio_blk.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 0e99a4714928..25a0a85a19fc 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -1591,9 +1591,12 @@ static void virtblk_remove(struct virtio_device *vdev) static int virtblk_freeze(struct virtio_device *vdev) { struct virtio_blk *vblk = vdev->priv; + struct request_queue *q = vblk->disk->queue; /* Ensure no requests in virtqueues before deleting vqs. */ - blk_mq_freeze_queue(vblk->disk->queue); + blk_mq_freeze_queue(q); + blk_mq_quiesce_queue_nowait(q); + blk_mq_unfreeze_queue(q); /* Ensure we don't receive any more interrupts */ virtio_reset_device(vdev); @@ -1617,8 +1620,8 @@ static int virtblk_restore(struct virtio_device *vdev) return ret; virtio_device_ready(vdev); + blk_mq_unquiesce_queue(vblk->disk->queue); - blk_mq_unfreeze_queue(vblk->disk->queue); return 0; } #endif