From nobody Sat Feb 7 04:57:01 2026 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 CD9C17E105 for ; Mon, 22 Dec 2025 20:16:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766434578; cv=none; b=Gj4xOcYyAQGs2DTTFruLRLTznLNFZfp/VNltmC/jDAQA+2WpZVnLDkEmReCzdiRR/8tJ/N8b9cMmtSP0HuMRbGHpPptyh4m5xR3RcqldXZoZ17I4y03cxrmERqxz5GlPimi05kgkws3bCOX+Xnt1h9D12y2wjwwQaaBpRJAtKk0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766434578; c=relaxed/simple; bh=o+vEFROiqUoDAPTJIDN1NXPMAkTeLu+cB5g1KoffBU8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OTuqpguBvMNt6QH6rtvNxW/JX8+VYofX6M28vIHJvMh701HUTfbgjK3s4RBQooJqcyYhEyh3F5XsbE/YtPBvDha9V3MuzDnLVHYJ2JLpgxTHu0rZTLmMvI+e4lJkRnw6vkQaMk4dqkh79CZgyL2K8QvSH9rQWKJ1cvmUh90I13Y= 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=NgHTrhDa; arc=none smtp.client-ip=209.85.214.169 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="NgHTrhDa" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2a137692691so50335715ad.0 for ; Mon, 22 Dec 2025 12:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766434576; x=1767039376; 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=NgHTrhDaWxgLy5d2rvpOBnTTvvfF1rnRysmlCB5uWDsfO9ieNB5TNv/BygfS9EW6Xj VjEUO68u5qGnDUmcw2Of2CjPodC+OyiLpGM1bMlXlFde30tuuGjrEV8X2648HElW8Y1Z 1Y3KZpuzivSD+yvPY+bzJ18TrC+Khgve50tRNHEebwlyKtX5ORADT+ZKM3Ddhchhri0Q bkr+eZqpIRxoBCon7hs0qbW+HIwxFRnfB3CNI0/7b9mLzYH3jT+ATzvD2UvI+MW8Ka/0 7ABxTTdRZgMjRayCCrhgG1pYQeYFiJAaVMkz406yb0hOlNHFnWScJ5C8uDpE8KJ7icYd me6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766434576; x=1767039376; 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=Xk78fCpsPA4MsdjPMKCDy67K5AtogzNYbJcenrZ1rV9t62YZMBTqgza5lIZg5YMR8G u/MujJxvPCD/gZNRN2yRFEC1uqWaLHOdyujsUUib+8jKOE8kTfdFi2UvE/F6lMks+ytI oyAVxALpKTZseuHsYjIGZtFg6+hrarPrQa7CQBaeERA1aqGVurco12ZFgMzr6LQaojKT JBcP8zkRPBa+p7yLk09H9iGZFAudQ8QbYRWaB7pt9IT4qbxISAmtoVe/5lxx/wDzXDLn WHanld3fC5ET+YZVDhYi3EgktDKbn7561EFbNHQ139pzDrPHxVi3RoFFc5ieWCDAk/v9 sl6g== X-Forwarded-Encrypted: i=1; AJvYcCWr7Njai8a5QowWMm2BxZFIHDocAd4brAALPpWaz+x7lYDgVPsGZPXQzozIYvR0tpBA54M4j8ZL2eJGos4=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8zmSfTaGIBWiSDom0tWF8BXKiOLC7Ae2CuJ48SNiBrJ5adIXZ L2sPDyXwfjp9qHgUOcHa/u3a8h/4jNNGCASTb4OksEgYvquP7/vHaYkzfZkh/op4 X-Gm-Gg: AY/fxX7vvzAUttZa5o4ISvGcJ07PYQdHRVjrBipR5asPQZex6wWr6EKNEg/uquFX03Q FuwPNIgfobmFXwVdpVvDk536Qe6fe1nBmq9fln+eWOpiX6W8hEyzpF+8li9FeiZm7VZoYMNGypJ r/jjM6DZuOMxIhxaK/pKZLFY9BrLQY46zkSWfbgJ+Pt9sY/BvZy9AuGmE1Uc7VXZAd3+ueBdxJj 7NQFq9LOAIsCi6fd3UgfHqcjz4ySV2axElMg7iNGzJurCg3xB8vAQzul5OxRBFEHaJWqq0+TpsI 7b+D2yTNRbyuieRX2/8gG91q0yoTQ2kURFuho4vE1+kyN/vs+pKLf0ygQEcKIcId7zICBtfurvw 6TIaTCIo2oqykA5fXmBFhT0OjVMf7ndL+30UenA81UatS48zbclHv9IUsSgP6y0cl6TCkdAGZNP d+gGzQGqtsuO40PPsRQ5C2cBD3AaykWviwydwpfJo6WgtY X-Google-Smtp-Source: AGHT+IGGCPRsUbtdnSyNVH6HcSffxoPpOEnbF7UGpOntHaM5661Ya5XibckfxkPrf4FjkYaBiYk8BQ== X-Received: by 2002:a17:903:120b:b0:294:def6:5961 with SMTP id d9443c01a7336-2a2f2840071mr108551835ad.45.1766434575985; Mon, 22 Dec 2025 12:16:15 -0800 (PST) Received: from ionutnechita-arz2022.local ([2a02:2f07:6016:fa00:48f6:1551:3b44:fd83]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a2f330d25esm104358905ad.0.2025.12.22.12.16.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Dec 2025 12:16:15 -0800 (PST) From: "Ionut Nechita (WindRiver)" X-Google-Original-From: "Ionut Nechita (WindRiver)" To: ming.lei@redhat.com Cc: axboe@kernel.dk, gregkh@linuxfoundation.org, ionut.nechita@windriver.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, muchun.song@linux.dev, sashal@kernel.org, stable@vger.kernel.org Subject: [PATCH v2 1/2] block/blk-mq: fix RT kernel regression with queue_lock in hot path Date: Mon, 22 Dec 2025 22:15:40 +0200 Message-ID: <20251222201541.11961-2-ionut.nechita@windriver.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20251222201541.11961-1-ionut.nechita@windriver.com> References: <20251222201541.11961-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 Sat Feb 7 04:57:01 2026 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 7A39D1DF261 for ; Mon, 22 Dec 2025 20:16:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766434586; cv=none; b=seLfZcoEWniBVGKp5zlrLVwwUGODyI8Jab4+8q2jXAZnqB+CYSL0WnmCBGhC5KrZO6f1AuVJw4MJTBtq2GpqVDE/rz0YvSGHZAdW83GjVDQJiSuVn+2HuLEilceqO7P3A2B9I2CPBP2EtuwuhQAcJRfIDnZ0HME9SwnrbOu/sOM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766434586; c=relaxed/simple; bh=3x2Lp7T3cj30BgxZkRxFd7fJ+xGEmQsAhJosfnJWiuQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tOFF2a+4YrJi4xtmkj96QK3i4kbntYtlH48r7VE//sRPjxJA9fzVTen/GeX/KnNgNRIxL14eAefh9QuDiwvH+0T6+dazdWNnhrcagToWJTLKYah68P4bqStFatmFyqDqWyBDjOMREDDM2/m9Exx/pbB2SnJ8fLF9+LDkHqLV+wY= 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=bJEg+tDL; arc=none smtp.client-ip=209.85.214.175 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="bJEg+tDL" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2a137692691so50336805ad.0 for ; Mon, 22 Dec 2025 12:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766434585; x=1767039385; 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=BMa3wSdMVGXj95ioxBEETokGr7K3zu5ogl1WC04RcvM=; b=bJEg+tDLBFTO7opn1G4RGReec6Azmzxr8iBknbErFPZXfCNBLPUMluBhvS85bNb71z NWM2SF4qmAETCuEeZrBcFU4Z/C+Vwah7HAhAPTvy7Yqik+YEmUcMtYzK04F5UL+0gy90 bDC1f+6bAbbgYYWl6ZtIdjmzWvXfHDEEHkPeohbx10u+yQT9Btw97q+jsOjGFXbKZwO6 PNVIJLv/EP0hHPV+u8mC4V7KBfnUsOBk6zX6jyj5q2KQuxbi3d8vJyZpth9Up+HSiak/ 556Z/F3KWEEfl4XxSi22at7SAOFwiqvCf8NULOmFWL18yBF8Nz+iN3WsPwwU18QWhjmr Go+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766434585; x=1767039385; 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=BMa3wSdMVGXj95ioxBEETokGr7K3zu5ogl1WC04RcvM=; b=xUyR2m3P+WgKpury5/Ue/29OSFb2MEhr4z6ag2v8xLVC8FW67lso1dAqwp82eWKaNX awDrBNw7zXOsaG2X6rQJukP45d6i22M73FlZDuIWN/2sJnPvCEsMsWJLVIq5LVKWXc4q 8qOlwChriIpOgu3khvUsebEVd/z9nTi8TmrbLVJlF+rOqs9CAQNhkMO+yi647tEcxq2y qPLVBovISVDBztDM2ZoXt3Wbw6Rg305gODflSTTPV+PkEXCFOEE10ha+JLQKt5w4bjKl qJpvgUllpkkA30fw+tcT8tkhzGhn7tugXKs5FdezjRzC51QjlPW7F5Q6f/iBBRRRZ6+D Njyg== X-Forwarded-Encrypted: i=1; AJvYcCUK5pP+qNXtfiSajHxDNQ+yyfBdgHsk43kZSMdSnJAn7t2g406RMGARwdN9TnFwNyVCNoB+iYawWDLUXCI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1gkqvb9P2LK3Zo8sasglsbXCNpu4E9rP3MWIXSxvgi3cf1Qnd 4cJpBynU20v7sBmrbf61qXO5FwcKbCwB3A98PkE26MN0z92OM4q/10kqqgBug+Rl X-Gm-Gg: AY/fxX549qpWg6fXq70CeGrzgUT7L/hadAH8tAbcLF14BvfzW5kf3hTDUQ4Z9iMjcEZ Sq6XEAYDYPEaMOttJ4ydUoT1YO6wPk8kJ2QKyg0HTbHztQXvMP40zofBJutSnnPXXGmByQxJ7FV H+7zeN+V1ZJk08/zlM1n0MiFlOGUospyRJnhREKQsymHIOwM8rwy8A+ENmRCuQJ8s0qZ7QaDFH4 7rgC1Ws1pj8EH99y+A8ccaqBtGAfofL0bdmyI43Z3pBjCeBnL43D2BL9ir21gaoAl7Qt5cIGzbk VpRy80eaHm5nLV7XXUZc+8yQIUo0Pm1KOumWeRDyU8r5MPJHBH1UopD8nOnNmGbyCxZVDUaMY0c v9IBQHhH9MBkFPvBO0twdW524l3qpmJux8ibT0vRFBY7cnFApOYer9VdLWtdcIaqBXn88O+lKpd ezaFycQJHCPxPgt7e6iVfDYcHqXRllSwWNO2fAEtJMpC9l X-Google-Smtp-Source: AGHT+IEuB211eJrtXYRtnAbPwZHFAJ3Laogx7YmJ49X41eVrFL8nNlqqmkk/chtEKcpdAsKs+c3xJw== X-Received: by 2002:a17:903:2a8b:b0:2a0:823f:4da6 with SMTP id d9443c01a7336-2a2f2a34f28mr112442415ad.50.1766434584602; Mon, 22 Dec 2025 12:16:24 -0800 (PST) Received: from ionutnechita-arz2022.local ([2a02:2f07:6016:fa00:48f6:1551:3b44:fd83]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a2f330d25esm104358905ad.0.2025.12.22.12.16.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Dec 2025 12:16:24 -0800 (PST) From: "Ionut Nechita (WindRiver)" X-Google-Original-From: "Ionut Nechita (WindRiver)" To: ming.lei@redhat.com Cc: axboe@kernel.dk, gregkh@linuxfoundation.org, ionut.nechita@windriver.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, muchun.song@linux.dev, sashal@kernel.org, stable@vger.kernel.org Subject: [PATCH v2 2/2] block: Fix WARN_ON in blk_mq_run_hw_queue when called from interrupt context Date: Mon, 22 Dec 2025 22:15:41 +0200 Message-ID: <20251222201541.11961-3-ionut.nechita@windriver.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20251222201541.11961-1-ionut.nechita@windriver.com> References: <20251222201541.11961-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 Fix warning "WARN_ON_ONCE(!async && in_interrupt())" that occurs during SCSI device scanning when blk_freeze_queue_start() calls blk_mq_run_hw_queu= es() synchronously from interrupt context. The issue happens during device removal/scanning when: 1. blk_mq_destroy_queue() -> blk_queue_start_drain() 2. blk_freeze_queue_start() calls blk_mq_run_hw_queues(q, false) 3. This triggers the warning in blk_mq_run_hw_queue() when in interrupt con= text Change the synchronous call to asynchronous to avoid running in interrupt c= ontext. Fixes: Warning in blk_mq_run_hw_queue+0x1fa/0x260 Signed-off-by: Ionut Nechita --- block/blk-mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 5fb8da4958d0..ae152f7a6933 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -128,7 +128,7 @@ void blk_freeze_queue_start(struct request_queue *q) percpu_ref_kill(&q->q_usage_counter); mutex_unlock(&q->mq_freeze_lock); if (queue_is_mq(q)) - blk_mq_run_hw_queues(q, false); + blk_mq_run_hw_queues(q, true); } else { mutex_unlock(&q->mq_freeze_lock); } --=20 2.52.0