From nobody Sun Feb 8 16:12:10 2026 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) (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 F24B93090CC for ; Sat, 20 Dec 2025 11:03:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766228598; cv=none; b=jrAIIO/lYqwPkOoW4BNGAguDpMzawM/W2Ct7Pkntd7V1ZgJRHj8kgNX5uLJvID4lrxIAV4bkvWkP0eCpkUNIf0x+07Axazj+Vua1CoEll+ttJPu468X+Zuihl2AyNFE8M+bdgtQZhUjagdWDzI3Zlni4F+kG5YM6p8IMzF+61No= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766228598; c=relaxed/simple; bh=o+vEFROiqUoDAPTJIDN1NXPMAkTeLu+cB5g1KoffBU8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t5NAhFiVbF8NiYlaaBjo/iUb9eiUu+EpQO9r/i0VwY/U1EreTuy4RgvzyKEB1L8eyy4mcUuarkzkp87K5TSFODuFT3UVOCG5pALQYEeBdlRjeEl1QIKN4XtDlgGP9qN5qFNqd4oqBinjJTHrSSjDox0Qi6TyI28B9OBHE33vjeM= 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=SqTeyUF5; arc=none smtp.client-ip=209.85.210.170 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="SqTeyUF5" Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-7b9c17dd591so2286917b3a.3 for ; Sat, 20 Dec 2025 03:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766228595; x=1766833395; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=QmUq8CHI3JkNtGWiGFMZyA0zmDp2QcgRy2thJxu/yXE=; b=SqTeyUF5qSB0bWs/TjWh+IANzwyLtcU5nZKbZVxUQ4kIZfqGv7kp5vMG8qM+rxE0ff y0j/WO3b8WIM34PoCjukuO8+TFJc6HU51pbvTkMlDlUj4asMiiNy5ongYqZ5xDBPvYRe WayxD91Nlo0j2m0VptnpkYIo4ITdeJMBtVXZMstNL5uRIid0soNprtOkLSAUnploWrko 6I96mKkmgIuXkzcuU1rinI9xp59gxKVxb+6Dgptt/Zi0M3f1l9TlXnMdVt7iv2VQ/2M2 dIO88u5sXC4Nd8jzeGlHAbCSPvb2ERUiNIxd71twmGyci7GbwHAwq01eCDlpksiW9jg5 88wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766228595; x=1766833395; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=QmUq8CHI3JkNtGWiGFMZyA0zmDp2QcgRy2thJxu/yXE=; b=hAEeMUFmXS5q+mAoV3877poLMaxgrD5J9LYnSwclzCROSB0d58U/P00UzH2x9Mrg/G s0CVy6eZM1wl3hQszLgxHvWROQ0m8ja0WM1GuuXXZEIpyUVqW+TPx9w5NjHFPzAQ4fb2 sLVJcAOCzK8pRNHm11bFNzcI2fz3p8f+YySZPoYYoRW8flSTKmy14kPLpdrQ6DLFA7ef Xyfz1S3PJxiC4OUPGjqlsYNSfG7+xn5M6JYcVw8gOw08EtfeZxxdj6TjF99zcecfTwlg bfr2foejjZ3pR8Ga2mgxyWNnPdadQ7VNTdbsIXzMs6yC212/BQPuJEkDNj95R/Rt+oia o3Kw== X-Forwarded-Encrypted: i=1; AJvYcCXThSAR49vfwqEO5TL8X73R04lMxAhivz1KIP4ACg6U6eGMawnf2aJyEDsDbhFMQTNNpbGD5HKeqHtc37Q=@vger.kernel.org X-Gm-Message-State: AOJu0YyWM2j8C3A7NOMyfy4cEPsXVSFK47wVfj5hVFXfR/WdWJv7D1gg tetz6dGzj0N0onHdxPiuVkanfE7a8RqUarxT+VegaCtd8ioRxN77jC9P X-Gm-Gg: AY/fxX6F+gNUXKbxC8cIosgWDsJeFwQxrQMr1w5KtFLAODSXVxgTLakt+1JwW/Nqf57 UiSvB9EI2ADYj8DMMJWD+0NpX3ZZQZj3RPgexjLBcVgYwqXzxGwmY2EFHKxEV1zVQTPBCxF3z6R F8m0+FnYpTx81LALM3SfKP64f/alhWrRwP6nfImts04sX7YeTT4aq1H/HHhIoXLYSnjKw82U3pr PFCzP0jgx+ic7jhvWZ7QGAj5xzU9bO1Dc8v85bR696zFi73D1wNgnFyunLG+0zlicN6BvOV/EhC jgO8Xn24HyorlVKF/x2fm+XsusuO5lZmaEp5vXbQ+fWelNGOjJJtOrwXXUAN+RbHm2cweU0GaY9 PTiy7zIUqYK9i+sBqXyRXN+UJnFsLvmAHM0ATJFB3yjOWHWFmReXyFRZKjaQvtLbooUqn0SLTcB naKoHTcAIbVcGTdJuPBJJJXBuuVLV9xJUfJqNB1UixKufeO+dXklQ= X-Google-Smtp-Source: AGHT+IGbAZ0JhMv5C7UPQHUgypPKxamy+ux8uZDHLsQ7+9J/dXNnA0eGTxwDCnt+Pb+rIopbPEgwTA== X-Received: by 2002:a05:6a00:e11:b0:7b9:4e34:621b with SMTP id d2e1a72fcca58-7ff6421137cmr4854852b3a.12.1766228595290; Sat, 20 Dec 2025 03:03:15 -0800 (PST) Received: from ionutnechita-arz2022.localdomain ([2a02:2f0e:c406:a500:4e4:f8f7:202b:9c23]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7a84368dsm5015547b3a.2.2025.12.20.03.03.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Dec 2025 03:03:14 -0800 (PST) From: "Ionut Nechita (WindRiver)" X-Google-Original-From: "Ionut Nechita (WindRiver)" To: axboe@kernel.dk, ming.lei@redhat.com Cc: gregkh@linuxfoundation.org, muchun.song@linux.dev, sashal@kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Ionut Nechita Subject: [PATCH 1/2] block/blk-mq: fix RT kernel regression with queue_lock in hot path Date: Sat, 20 Dec 2025 13:02:40 +0200 Message-ID: <20251220110241.8435-2-ionut.nechita@windriver.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20251220110241.8435-1-ionut.nechita@windriver.com> References: <20251220110241.8435-1-ionut.nechita@windriver.com> 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" From: Ionut Nechita Commit 679b1874eba7 ("block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding") introduced queue_lock acquisition in blk_mq_run_hw_queue() to synchronize QUEUE_FLAG_QUIESCED checks. On RT kernels (CONFIG_PREEMPT_RT), regular spinlocks are converted to rt_mutex (sleeping locks). When multiple MSI-X IRQ threads process I/O completions concurrently, they contend on queue_lock in the hot path, causing all IRQ threads to enter D (uninterruptible sleep) state. This serializes interrupt processing completely. Test case (MegaRAID 12GSAS with 8 MSI-X vectors on RT kernel): - Good (v6.6.52-rt): 640 MB/s sequential read - Bad (v6.6.64-rt): 153 MB/s sequential read (-76% regression) - 6-8 out of 8 MSI-X IRQ threads stuck in D-state waiting on queue_lock The original commit message mentioned memory barriers as an alternative approach. Use full memory barriers (smp_mb) instead of queue_lock to provide the same ordering guarantees without sleeping in RT kernel. Memory barriers ensure proper synchronization: - CPU0 either sees QUEUE_FLAG_QUIESCED cleared, OR - CPU1 sees dispatch list/sw queue bitmap updates This maintains correctness while avoiding lock contention that causes RT kernel IRQ threads to sleep in the I/O completion path. Fixes: 679b1874eba7 ("block: fix ordering between checking QUEUE_FLAG_QUIES= CED request adding") Cc: stable@vger.kernel.org Signed-off-by: Ionut Nechita --- block/blk-mq.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 5da948b07058..5fb8da4958d0 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2292,22 +2292,19 @@ void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx= , bool async) =20 might_sleep_if(!async && hctx->flags & BLK_MQ_F_BLOCKING); =20 + /* + * First lockless check to avoid unnecessary overhead. + * Memory barrier below synchronizes with blk_mq_unquiesce_queue(). + */ need_run =3D blk_mq_hw_queue_need_run(hctx); if (!need_run) { - unsigned long flags; - - /* - * Synchronize with blk_mq_unquiesce_queue(), because we check - * if hw queue is quiesced locklessly above, we need the use - * ->queue_lock to make sure we see the up-to-date status to - * not miss rerunning the hw queue. - */ - spin_lock_irqsave(&hctx->queue->queue_lock, flags); + /* Synchronize with blk_mq_unquiesce_queue() */ + smp_mb(); need_run =3D blk_mq_hw_queue_need_run(hctx); - spin_unlock_irqrestore(&hctx->queue->queue_lock, flags); - if (!need_run) return; + /* Ensure dispatch list/sw queue updates visible before execution */ + smp_mb(); } =20 if (async || !cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask)) { --=20 2.52.0 From nobody Sun Feb 8 16:12:10 2026 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (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 1F2593090DB for ; Sat, 20 Dec 2025 11:03:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766228604; cv=none; b=q27+vHnyvJI3YZH6IsVoYGJJpU5akwni0seKUvBWEP6taEls3t/OOzxTH6hsRIHaRFRfF65zxVU481xSUD2MaTBfxqddAK+oegjmcDrRMEYYaLEs6jWt6I+q7ssBedCmRUs6BSB5PtNcsrDGub+40KlW1u1MjIcay+YET6bLtvY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766228604; c=relaxed/simple; bh=qZiaWUijlwHeE8abhYVQrGh0Ck6Xhq/A2Ir5bDcfcM8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ksKz8APyTcjh2qPL1TQf+kNeJCDtypYiuajdgohyxfGX9LxiHXcjgKT9Rqt6bFI8r7QEpvR0lFjAOXU7R5MjVpq4gd7rBCRjyY8MPnzAIlounAo5M4r3+eXBE5sSO+uUnIFgSPgCbfJZy/ktfAS2xoJhNUJ/F+/kvJm4hQoUbtA= 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=GvL7IudY; arc=none smtp.client-ip=209.85.210.178 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="GvL7IudY" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-7b22ffa2a88so2501940b3a.1 for ; Sat, 20 Dec 2025 03:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766228602; x=1766833402; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oS9W7wjkO+D9K7hG07rgBpqwDj1jVarCsyxehEZuYco=; b=GvL7IudYsd4mNxLK9s83kWth3f0hrFRMnhM2YW18kHzvM1Xb71vc9Lvs+wBSeF+Irr pPUV4J/PzyGOmDSO01LJhQBzICQ2YBQjQfCnt2g69miig6RfX9+JKtNtc+44Z/BmpAxt UhoJIpQw3aUwT9FiAo5XguuopElwL697cyFwZyANfNuCW2mCwRsmqrESkveiQ+II1QyQ Z+t5r59/DNVQVsXx/JK1qXrjP8aeJRZqopucPiM7USrKEFGp3kUObFLDIajHeFa/W+/N ztGoy386UXlKzDXwpoAiDgxsZQi3aR8zm3UYfSuFSmQddgOG5Hc7whK7Z/TCaW9f2E6+ YDNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766228602; x=1766833402; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oS9W7wjkO+D9K7hG07rgBpqwDj1jVarCsyxehEZuYco=; b=iujJU8OSHJC9y9OqWuyFC5f8hXxk5Yssx1MFjADXiJmO6nPT2pPy5v66+VTAF5hYmN MQEGJRWYWvtaUvwdWZjwXZLIA7cBTc3isNkQTqVSqwdwrvdBm+mFPV6eOk3e40kA4ub4 JdqQwsx59nWT/7pvmBGMvSa7bkfCvq9s346aw/3v4tbqqWD8YVhi1y60E3Kjgw7TeaCV PxPteH20/ursxiYkouDuc9hCSYGoWQ4jgKr7Lunbtt01jv3y8CuhSAUkLOr5INfXWNal BLyrKDxkIuSKCfIdQWaE/BzjZIfWVHHcijltBcKTSvSNudl0CYOMsAdldrEGn7PuZlyA f21Q== X-Forwarded-Encrypted: i=1; AJvYcCUIjqO/EF9Sqb613hhj5mZtZB4crUSKmf/8Wrxhr+dFc/uZNgaLWSCvi4g9PJEuBQLU6K+0rtBwuGI0KwM=@vger.kernel.org X-Gm-Message-State: AOJu0YwWmzdncFAZMergTBP32wx5N5MhRxC3k3HM6/dXQkMLQHPL6jom UNh8ugyvAQEvEWIkt+u5lxmLnecNodj8VxYaq7Bs/tVnDEcwxcqBfO6iqKgHeQ== X-Gm-Gg: AY/fxX6+W95M4FS/2IirWGCfo1tNjqRdJ7LoF+kdFwDk/DIQs9kXzI1l96lqekhfWvo b6Yu+D5QmhmfoGSWjh342eAyeyg5dOW+oga4fj8B3eqWq3tVr3pnhkQdKFZ8ti21Ldu/EU9uBPQ M1KBxr5AwZG4FLvOQunnyYapQ3mtHVpAFpYqjmt2IixP1dEg51zF/RusRHFfQ0rNnSWmWwXjUvP NRH1lXcXiIzwHFNqgJkHa0hRxFAyQGITfjVYedDIRO2TK8cQAfWNA8RbeblI41YKZIcGotW3Mk1 iFUWaAr4SSsxbGiwtJMrItxTIo+iCprFfOnm3lHWRqwNCQL7J7wm3ynJn/YPWHWnUsN9zezkK0l puWvnGOHhFG52w3D3BTmWiHraaVVU4StzMZwFsFztu/qcCg1l3jYkWX0ZoGwGSROoS3t3Tdsug6 Mu3aVdSCHjMYxzEvqWjscxoM3mU/Ei7JBaZgaCUOTTCovQQoU9ZwU= X-Google-Smtp-Source: AGHT+IF/P/WLJTzCtGkWHYUlpb9xLBtbrMR9kXyxku3L04FO5e2ykvbYbKXn1q2ANA8kjw0xzemWug== X-Received: by 2002:a05:6a00:3014:b0:7e1:b7ba:d5a2 with SMTP id d2e1a72fcca58-7ff61b8b53fmr5213055b3a.0.1766228602348; Sat, 20 Dec 2025 03:03:22 -0800 (PST) Received: from ionutnechita-arz2022.localdomain ([2a02:2f0e:c406:a500:4e4:f8f7:202b:9c23]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7a84368dsm5015547b3a.2.2025.12.20.03.03.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Dec 2025 03:03:21 -0800 (PST) From: "Ionut Nechita (WindRiver)" X-Google-Original-From: "Ionut Nechita (WindRiver)" To: axboe@kernel.dk, ming.lei@redhat.com Cc: gregkh@linuxfoundation.org, muchun.song@linux.dev, sashal@kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Ionut Nechita Subject: [PATCH 2/2] block/blk-mq: convert blk_mq_cpuhp_lock to raw_spinlock for RT Date: Sat, 20 Dec 2025 13:02:41 +0200 Message-ID: <20251220110241.8435-3-ionut.nechita@windriver.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20251220110241.8435-1-ionut.nechita@windriver.com> References: <20251220110241.8435-1-ionut.nechita@windriver.com> 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" From: Ionut Nechita Commit 58bf93580fec ("blk-mq: move cpuhp callback registering out of q->sysfs_lock") introduced a global mutex blk_mq_cpuhp_lock to avoid lockdep warnings between sysfs_lock and CPU hotplug lock. On RT kernels (CONFIG_PREEMPT_RT), regular mutexes are converted to rt_mutex (sleeping locks). When block layer operations need to acquire blk_mq_cpuhp_lock, IRQ threads processing I/O completions may sleep, causing additional contention on top of the queue_lock issue from commit 679b1874eba7 ("block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding"). Test case (MegaRAID 12GSAS with 8 MSI-X vectors on RT kernel): - v6.6.68-rt with queue_lock fix: 640 MB/s (queue_lock fixed) - v6.6.69-rt: still exhibits contention due to cpuhp_lock mutex The functions protected by blk_mq_cpuhp_lock only perform fast, non-sleeping operations: - hlist_unhashed() checks - cpuhp_state_add_instance_nocalls() - just hlist manipulation - cpuhp_state_remove_instance_nocalls() - just hlist manipulation - INIT_HLIST_NODE() initialization The _nocalls variants do not invoke state callbacks and only manipulate data structures, making them safe to call under raw_spinlock. Convert blk_mq_cpuhp_lock from mutex to raw_spinlock to prevent it from becoming a sleeping lock in RT kernel. This eliminates the contention bottleneck while maintaining the lockdep fix's original intent. Fixes: 58bf93580fec ("blk-mq: move cpuhp callback registering out of q->sys= fs_lock") Cc: stable@vger.kernel.org Signed-off-by: Ionut Nechita --- block/blk-mq.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 5fb8da4958d0..3982e24b1081 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -43,7 +43,7 @@ =20 static DEFINE_PER_CPU(struct llist_head, blk_cpu_done); static DEFINE_PER_CPU(call_single_data_t, blk_cpu_csd); -static DEFINE_MUTEX(blk_mq_cpuhp_lock); +static DEFINE_RAW_SPINLOCK(blk_mq_cpuhp_lock); =20 static void blk_mq_insert_request(struct request *rq, blk_insert_t flags); static void blk_mq_request_bypass_insert(struct request *rq, @@ -3641,9 +3641,9 @@ static void __blk_mq_remove_cpuhp(struct blk_mq_hw_ct= x *hctx) =20 static void blk_mq_remove_cpuhp(struct blk_mq_hw_ctx *hctx) { - mutex_lock(&blk_mq_cpuhp_lock); + raw_spin_lock(&blk_mq_cpuhp_lock); __blk_mq_remove_cpuhp(hctx); - mutex_unlock(&blk_mq_cpuhp_lock); + raw_spin_unlock(&blk_mq_cpuhp_lock); } =20 static void __blk_mq_add_cpuhp(struct blk_mq_hw_ctx *hctx) @@ -3683,9 +3683,9 @@ static void blk_mq_remove_hw_queues_cpuhp(struct requ= est_queue *q) list_splice_init(&q->unused_hctx_list, &hctx_list); spin_unlock(&q->unused_hctx_lock); =20 - mutex_lock(&blk_mq_cpuhp_lock); + raw_spin_lock(&blk_mq_cpuhp_lock); __blk_mq_remove_cpuhp_list(&hctx_list); - mutex_unlock(&blk_mq_cpuhp_lock); + raw_spin_unlock(&blk_mq_cpuhp_lock); =20 spin_lock(&q->unused_hctx_lock); list_splice(&hctx_list, &q->unused_hctx_list); @@ -3702,10 +3702,10 @@ static void blk_mq_add_hw_queues_cpuhp(struct reque= st_queue *q) struct blk_mq_hw_ctx *hctx; unsigned long i; =20 - mutex_lock(&blk_mq_cpuhp_lock); + raw_spin_lock(&blk_mq_cpuhp_lock); queue_for_each_hw_ctx(q, hctx, i) __blk_mq_add_cpuhp(hctx); - mutex_unlock(&blk_mq_cpuhp_lock); + raw_spin_unlock(&blk_mq_cpuhp_lock); } =20 /* --=20 2.52.0