em passed) 3. On failure, it returns 0 or EOF 4. The check 'if (!sscanf(...))' is wrong because it treats success (1) as failure All occurrences of sscanf() now uses explicit return value check. With this behavior it returns '-EINVAL' when parsing fails (returns 0 or EOF), and continues when parsing succeeds (returns 1). Signed-off-by: Sumeet Pawnikar [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20251207151549.202452-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Looking at this commit carefully to assess its suitability for stable backporting. ## Commit Analysis ### 1. COMMIT MESSAGE ANALYSIS The commit fixes incorrect error handling for `sscanf()` return value checks in the powercap subsystem. The message claims that `if (!sscanf(...))` is wrong because: - `sscanf()` returns the number of successfully parsed items - On success: returns 1 - On failure: returns 0 or EOF (typically -1) ### 2. CODE CHANGE ANALYSIS Three identical changes in `drivers/powercap/powercap_sys.c`: ```c // Before: if (!sscanf(dev_attr->attr.name, "constraint_%d_", &id)) // After: if (sscanf(dev_attr->attr.name, "constraint_%d_", &id) != 1) ``` Let me trace through the bug: - When `sscanf()` returns 0 (no match): `!0` = 1 (true) → error path taken ✓ - When `sscanf()` returns 1 (success): `!1` = 0 (false) → continues ✓ - When `sscanf()` returns EOF (-1): `!(-1)` = 0 (false) → **error path NOT taken** ✗ The critical issue is the EOF case. If `sscanf()` returns EOF (e.g., empty string input), the check passes incorrectly and execution continues with an **uninitialized `id` variable**. This then leads to: ```c if (id >= power_zone->const_id_cnt) // garbage comparison return -EINVAL; pconst = &power_zone->constraints[id]; // POTENTIAL OUT-OF-BOUNDS ACCESS ``` ### 3. CLASSIFICATION This is a **bug fix** that prevents: - Potential out-of-bounds array access - Use of uninitialized variable - Possible kernel crash or memory corruption in edge cases Not a feature addition, code cleanup, or optimization. ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed**: 3 lines (identical pattern) - **Files affected**: 1 file - **Risk**: Extremely low - the change only makes the check stricter and more explicit - **Could break anything?**: No - the new check `!= 1` is strictly more conservative than `!` ### 5. USER IMPACT The powercap subsystem manages: - Intel RAPL power capping - Power domain constraints - Used by tools like powertop, thermald While the EOF triggering condition is rare (would require malformed attribute names), the consequence (OOB access) could be severe. ### 6. STABILITY INDICATORS - Signed-off by Rafael J. Wysocki (Intel power management maintainer) - Self-contained fix with no dependencies - The powercap subsystem has existed since kernel 3.13 ### 7. DEPENDENCY CHECK - No dependencies on other commits - Simple standalone fix - Code exists in all active stable trees ## Summary **What it fixes**: Incorrect sscanf error handling that could allow execution with uninitialized data, potentially leading to out-of-bounds array access. **Why it matters for stable**: While the triggering condition (EOF from sscanf) is rare, the fix prevents a potential memory safety issue. The change is trivially correct with zero regression risk. **Meets stable criteria**: - ✓ Obviously correct (explicit `!= 1` check is cleaner and more robust) - ✓ Fixes a real bug (uninitialized variable use, potential OOB access) - ✓ Small and contained (3 identical one-line changes) - ✓ No new features - ✓ No dependencies **Risk vs benefit**: The benefit (preventing potential memory corruption) outweighs the near-zero risk of regression. **YES** drivers/powercap/powercap_sys.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c index d14b36b75189..1ff369880beb 100644 --- a/drivers/powercap/powercap_sys.c +++ b/drivers/powercap/powercap_sys.c @@ -68,7 +68,7 @@ static ssize_t show_constraint_##_attr(struct device *dev, \ int id; \ struct powercap_zone_constraint *pconst;\ \ - if (!sscanf(dev_attr->attr.name, "constraint_%d_", &id)) \ + if (sscanf(dev_attr->attr.name, "constraint_%d_", &id) != 1) \ return -EINVAL; \ if (id >= power_zone->const_id_cnt) \ return -EINVAL; \ @@ -93,7 +93,7 @@ static ssize_t store_constraint_##_attr(struct device *dev,\ int id; \ struct powercap_zone_constraint *pconst;\ \ - if (!sscanf(dev_attr->attr.name, "constraint_%d_", &id)) \ + if (sscanf(dev_attr->attr.name, "constraint_%d_", &id) != 1) \ return -EINVAL; \ if (id >= power_zone->const_id_cnt) \ return -EINVAL; \ @@ -162,7 +162,7 @@ static ssize_t show_constraint_name(struct device *dev, ssize_t len = -ENODATA; struct powercap_zone_constraint *pconst; - if (!sscanf(dev_attr->attr.name, "constraint_%d_", &id)) + if (sscanf(dev_attr->attr.name, "constraint_%d_", &id) != 1) return -EINVAL; if (id >= power_zone->const_id_cnt) return -EINVAL; -- 2.51.0 From - Tue Dec 23 10:38:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id eGQVDipxSmmZLigAYBR5ng (envelope-from ) for ; Tue, 23 Dec 2025 10:38:34 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 23 Dec 2025 10:38:34 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vXzmj-0000000BEvg-3rnT for hi@josie.lol; Tue, 23 Dec 2025 10:38:34 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 95DBC3024E20 for ; Tue, 23 Dec 2025 10:37:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 847BB3502A5; Tue, 23 Dec 2025 10:05:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hbt7u+zP" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 336873502B9; Tue, 23 Dec 2025 10:05:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484327; cv=none; b=S/vnsC/s3yy3Z2ZX3hK7+Pi9KrlQc7uT2fs/P29V1h71u7IaL+WewiwUjR4h/JgdzqrVPdtD6Vv/DQoiEELxOFizQsmSKjKq7lfs6FKzFsbT3bNM14cvSImlqkyPrFPQBxseICnCdYzFvRQdLTDX0urU0i+cJ802gGJgO++djhY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484327; c=relaxed/simple; bh=ddQ4P35GJ65fx1phlIRY6geJ4UujdLlbIP6/qv+iUsg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VlZfbL6lvs0eOg+vzBYXAiJmWdOTIiI3aKYWYRsLks/I5U9b53+SPARM2HJW7A6Q8YcaLhUwG8tdlPmRM+0OoaSG0qOLgH3HsZ6pFjImFf7dRMdNNPiiVjSoAUKF8vY+pdNShpRHfbC9Hnmf3S5ChpxAuAYZHgBd5Fhq9mAJQZc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hbt7u+zP; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id D534AC16AAE; Tue, 23 Dec 2025 10:05:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766484326; bh=ddQ4P35GJ65fx1phlIRY6geJ4UujdLlbIP6/qv+iUsg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hbt7u+zPupAG5jcdaNAkQeWzPuyZEzDlio6UJw5q1tiO22mNq8jF/561nJftqLBWI BBDyNn6EJvUX2nu6SHGjRlWF9WFWMp+tnzOEIMggWMp+vcIUrxVX4SlbASBS78c4lT wf54uSHev0oqJ/e5LQpJAIIEhYYEz09UXSV6zyjo5oI2J1v1azR/morInAFfgfauyt 938sYYlKlcl45+F/BqxmW29FEUkDUTl2RdKHhYEKqyhvjuppg/FfuW35o53248+Rl0 4ciI2PCC5+X4+iNeKjm0NeSiKsslmfHWW+KNR39gKNfYD6CkYXazC+l1Ae9VljszET +mOmTXFl/uQsg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Caleb Sander Mateos , Christoph Hellwig , Jens Axboe , Sasha Levin , linux-block@vger.kernel.org Subject: [PATCH AUTOSEL 6.18] block: validate pi_offset integrity limit Date: Tue, 23 Dec 2025 05:05:10 -0500 Message-ID: <20251223100518.2383364-6-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251223100518.2383364-1-sashal@kernel.org> References: <20251223100518.2383364-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Caleb Sander Mateos [ Upstream commit ccb8a3c08adf8121e2afb8e704f007ce99324d79 ] The PI tuple must be contained within the metadata value, so validate that pi_offset + pi_tuple_size <= metadata_size. This guards against block drivers that report invalid pi_offset values. Signed-off-by: Caleb Sander Mateos Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Summary ### Problem Being Fixed The commit fixes an **incomplete bounds validation bug** in the block layer's integrity limit validation code. When the PI (Protection Information) tuple can be placed at a non-zero offset within the metadata buffer (a feature added in kernel 6.9), the validation check only verified that `pi_tuple_size <= metadata_size`, but **completely ignored the pi_offset**. This is mathematically incorrect. If: - `metadata_size = 8` bytes - `pi_tuple_size = 8` bytes - `pi_offset = 4` bytes The old check (`8 > 8`) passes, but the PI tuple would extend 4 bytes beyond the buffer boundary, potentially causing out-of-bounds memory access. ### Why It Matters to Stable Users - **Data Integrity Risk**: Block layer integrity/PI is used in enterprise storage environments (NVMe, SAS with T10 PI) - **Defense Against Buggy Drivers**: The fix prevents the kernel from accepting invalid configurations from misbehaving block drivers - **Potential for Memory Corruption**: Without this validation, accessing PI data could read/write beyond buffer bounds ### Stable Kernel Criteria Assessment | Criterion | Met? | Notes | |-----------|------|-------| | Obviously correct | ✅ | Mathematical correctness: offset + size must fit in buffer | | Fixes real bug | ✅ | Incomplete bounds check could allow invalid configurations | | Small scope | ✅ | 4 lines changed, single file | | No new features | ✅ | Only strengthens existing validation | | No API changes | ✅ | No user-visible changes | ### Risk vs Benefit **Risk**: Extremely low - The change only makes validation stricter - Can only reject configurations that were previously (incorrectly) accepted - Any configuration rejected by the new check was already semantically invalid and potentially dangerous **Benefit**: Moderate to high - Prevents kernel from accepting invalid integrity configurations - Guards against memory corruption in PI-enabled storage stacks - Important for enterprise environments using DIF/PI ### Concerns **Applicability**: The `pi_offset` field was introduced in kernel 6.9 (commit 60d21aac52e2). This fix is only applicable to stable kernels 6.9.y and later. **Dependencies**: None - this is a standalone validation fix. ### Quality Indicators - Reviewed-by: Christoph Hellwig (highly respected kernel developer) - Signed-off-by: Jens Axboe (block layer maintainer) - Part of a series of validation improvements (similar commit for `interval_exp`) - No follow-up fixes needed The fix is small, surgical, obviously correct, and addresses a real validation gap that could lead to memory safety issues. It meets all stable kernel criteria. **YES** block/blk-settings.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/block/blk-settings.c b/block/blk-settings.c index d74b13ec8e54..f2c1940fe6f1 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -148,10 +148,9 @@ static int blk_validate_integrity_limits(struct queue_limits *lim) return -EINVAL; } - if (bi->pi_tuple_size > bi->metadata_size) { - pr_warn("pi_tuple_size (%u) exceeds metadata_size (%u)\n", - bi->pi_tuple_size, - bi->metadata_size); + if (bi->pi_offset + bi->pi_tuple_size > bi->metadata_size) { + pr_warn("pi_offset (%u) + pi_tuple_size (%u) exceeds metadata_size (%u)\n", + bi->pi_offset, bi->pi_tuple_size, bi->metadata_size); return -EINVAL; } -- 2.51.0 From - Tue Dec 23 10:39:35 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id aBOAJ2NxSmlaJSYAYBR5ng (envelope-from ) for ; Tue, 23 Dec 2025 10:39:31 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 23 Dec 2025 10:39:31 +0000 Received: from sto.lore.kernel.org ([172.232.135.74]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vXznf-0000000BHRa-0wxy for hi@josie.lol; Tue, 23 Dec 2025 10:39:31 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id 88E09300181B for ; Tue, 23 Dec 2025 10:39:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 75606357A22; Tue, 23 Dec 2025 10:05:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org heade.org>) for ; Tue, 23 Dec 2025 10:40:26 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 23 Dec 2025 10:40:26 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vXzoY-0000000BJbA-10w1 for hi@josie.lol; Tue, 23 Dec 2025 10:40:26 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id AFC47307DF23 for ; Tue, 23 Dec 2025 10:36:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2E5CA35293E; Tue, 23 Dec 2025 10:05:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fKLFqC2U" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D487A3502B1; Tue, 23 Dec 2025 10:05:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484324; cv=none; b=SohFHcy9h83tXCfFK6L70m4Vf8N9zha+c0gSN+iyInkVK0lJz7BkzKxCj+/P19txr1+DJANej+QJ4WtAhQdtMngXG5+2WyOlP2rezi1rRDe/+wLM3OR7TuDS5/nQRJB3FkLLzZWBnB3HAhE5qVKNa4JGmvhTtkqkkKWou/sLVcY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484324; c=relaxed/simple; bh=/zYcG2xYSdYnuLSHKUx/IzmXhDPgwtNTHCfAvrduQQU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OcsQdNHKjoeMG2IS3TUxGLEzb1bdDASesp7MiQvrIIAEcOG1scjO2oEMOyZFkemtakvD0ZymNQ1cjNnoKUCaVkGVCdytRS5RGsNgezIFPhuCFtUayMsVMUPmGUU00JVh3vTOrDN8ZmjPC31C52RGPuGK0z1zuYIO/R4/Qu5tAJU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fKLFqC2U; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEDB3C19423; Tue, 23 Dec 2025 10:05:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766484322; bh=/zYcG2xYSdYnuLSHKUx/IzmXhDPgwtNTHCfAvrduQQU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fKLFqC2Uk/cCGXFRXMAn2Gzcw2zEpSryMzNseG+JvPxBF8EekqKOGdnG/KNk/s8/v HV4Y4xH1RZuMNpSqWtzbp5D1p4NZ3HMtz8kl1dGnfqkMmzAsxo8bNnfTs3Q4Kb3YuQ 0fo0oiZxQGYse9MTDFSVEw6mrVUJg9J3MHYV2vOZ1Q+Ec7ixU5NGk4aJXwHAUsfOIS 6z3ba3eJ5QoEmSPBLC9MnCHHm1EJ1Rj1v2tAGt/WCVSykxcD2rZRCXTdxbVOXzFVSt 386BYtxKRVwG68h186xPxLf218r6+T+4G6tdkVYnTSXb9FG9Gdm4/N74J80viarGH5 jxpDYjn7Vwgdg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Fei Shao , Mark Brown , Sasha Levin , matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: [PATCH AUTOSEL 6.18-6.12] spi: mt65xx: Use IRQF_ONESHOT with threaded IRQ Date: Tue, 23 Dec 2025 05:05:07 -0500 Message-ID: <20251223100518.2383364-3-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251223100518.2383364-1-sashal@kernel.org> References: <20251223100518.2383364-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: msgid.link] -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Fei Shao [ Upstream commit 8c04b77f87e6e321ae6acd28ce1de5553916153f ] This driver is migrated to use threaded IRQ since commit 5972eb05ca32 ("spi: spi-mt65xx: Use threaded interrupt for non-SPIMEM transfer"), and we almost always want to disable the interrupt line to avoid excess interrupts while the threaded handler is processing SPI transfer. Use IRQF_ONESHOT for that purpose. In practice, we see MediaTek devices show SPI transfer timeout errors when communicating with ChromeOS EC in certain scenarios, and with IRQF_ONESHOT, the issue goes away. Signed-off-by: Fei Shao Link: https://patch.msgid.link/20251217101131.1975131-1-fshao@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed:** 1 line - **Files touched:** 1 file - **Complexity:** Trivially low - just a flag change - **Risk:** Very low The fix is: - **Obviously correct**: IRQF_ONESHOT is the documented standard for threaded interrupts - **Small and contained**: One flag change - **Fixes a real bug**: Transfer timeout errors on real hardware Looking at the interrupt handler code: - `mtk_spi_interrupt` returns `IRQ_WAKE_THREAD` for non-SPIMEM transfers - Without IRQF_ONESHOT, the IRQ line stays enabled, allowing repeated interrupts while the thread processes - This causes race conditions on `mdata->state` and transfer handling, leading to timeouts ### 5. USER IMPACT - **Who is affected:** Users of MediaTek SPI devices, particularly ChromeOS users with embedded controllers - **Severity:** Medium-High - SPI transfer timeouts can cause significant functionality issues - **Real-world impact:** Confirmed on MediaTek devices communicating with ChromeOS EC ### 6. DEPENDENCY CHECK The prerequisite commit `5972eb05ca32` ("spi: spi-mt65xx: Use threaded interrupt for non-SPIMEM transfer") was first included in **v6.12-rc1**. This means: - This fix is only applicable to 6.12.y stable trees and newer - Older stable trees (6.6.y, 6.1.y, 5.15.y) don't have the threaded IRQ code, so this fix doesn't apply ### 7. SUMMARY | Criterion | Assessment | |-----------|------------| | Fixes real bug | ✅ Yes - SPI transfer timeouts | | Obviously correct | ✅ Yes - standard pattern | | Small and contained | ✅ Yes - 1 line change | | Tested | ✅ Yes - real hardware testing | | Risk | ✅ Very low | | Dependencies | ✅ Clear - requires 5972eb05ca32 (v6.12+) | ### Conclusion This commit is an excellent candidate for stable backporting: 1. **Fixes a real, user-visible bug**: SPI transfer timeouts on MediaTek hardware 2. **Minimal change**: Single flag addition, no logic changes 3. **Obviously correct**: IRQF_ONESHOT is the proper pattern for threaded IRQs with hardirq handlers that return IRQ_WAKE_THREAD 4. **Low risk**: Well-understood kernel mechanism with no side effects 5. **Tested**: Confirmed to resolve the issue on real ChromeOS EC hardware The only consideration is that this fix only applies to stable trees with kernel 6.12 or later (which contain the prerequisite threaded IRQ commit). For those trees, this is a straightforward, low-risk fix that resolves real hardware issues. **YES** drivers/spi/spi-mt65xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c index 4b40985af1ea..90e5813cfdc3 100644 --- a/drivers/spi/spi-mt65xx.c +++ b/drivers/spi/spi-mt65xx.c @@ -1320,7 +1320,7 @@ static int mtk_spi_probe(struct platform_device *pdev) ret = devm_request_threaded_irq(dev, irq, mtk_spi_interrupt, mtk_spi_interrupt_thread, - IRQF_TRIGGER_NONE, dev_name(dev), host); + IRQF_ONESHOT, dev_name(dev), host); if (ret) return dev_err_probe(dev, ret, "failed to register irq\n"); -- 2.51.0 From - Tue Dec 23 10:41:24 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id YOWvHtBxSmkxxCcAYBR5ng (envelope-from ) for ; Tue, 23 Dec 2025 10:41:20 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 23 Dec 2025 10:41:20 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vXzpP-0000000BNED-44Wf for hi@josie.lol; Tue, 23 Dec 2025 10:41:20 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id E17183095330 for ; Tue, 23 Dec 2025 10:36:53 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0DFEE35772C; Tue, 23 Dec 2025 10:05:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u9vNJBwB" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D828F35772A; Tue, 23 Dec 2025 10:05:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484331; cv=none; b=eDYZkfLkw5sAFbnyVP7eGV6tHPwlSazisT2G3ls81GDaX4mqht5dK9vyKZld/kK76lt59d4aHUEwMS2+SSztczKtDBXchnb8s694OorxC/7gaO2njlQSw0vZPQAXD38yQQPYIX2EuBO+u+qvRAvo+UBk9LM2/HUZjZoPYRXl4Jo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484331; c=relaxed/simple; bh=2bElGj6oTaVx916jVSsTwC8Pc7YB1+/6sP52v4v8qrk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=q0YNBP6I51J12a8KLOYJLsnW4ZI5mrgcw1R4Z/B/ibjUYy/4b6B1bAUPHvD8ddMRYF9iV7Xgd+4iHt0mr4BPJVIp06Kjz+TkEhfAOkxNwQQQ3UO/JBeER9dowoxDMZ+gPncn0INzjLNX3R8b7+hB4lc8v1sPj2HifY5rHE1yx94= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) hea