* Re: [PATCH v2 03/11] drm/msm/hdmi: switch to of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:31 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tian Tao, Xinwei Kong,
Sumit Semwal, John Stultz, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Tomi Valkeinen, Michal Simek, Hui Pu, Ian Ray, Thomas Petazzoni,
dri-devel, linux-kernel, linux-arm-msm, freedreno,
linux-arm-kernel
In-Reply-To: <20260428-drm-bridge-alloc-getput-panel_or_bridge-v2-3-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:49AM +0200, Luca Ceresoli wrote:
> This driver calls drm_of_find_panel_or_bridge() with a NULL pointer in the
> @panel parameter, thus using a reduced feature set of that function.
> Replace this call with the simpler of_drm_get_bridge_by_endpoint().
>
> Since of_drm_get_bridge_by_endpoint() increases the refcount of the
> returned bridge, ensure it is put on removal.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> drivers/gpu/drm/msm/hdmi/hdmi.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 02/11] drm/bridge: add of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:30 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tian Tao, Xinwei Kong,
Sumit Semwal, John Stultz, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Tomi Valkeinen, Michal Simek, Hui Pu, Ian Ray, Thomas Petazzoni,
dri-devel, linux-kernel, linux-arm-msm, freedreno,
linux-arm-kernel
In-Reply-To: <20260428-drm-bridge-alloc-getput-panel_or_bridge-v2-2-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:48AM +0200, Luca Ceresoli wrote:
> drm_of_find_panel_or_bridge() is widely used, but many callers pass NULL
> into the @panel or the @bridge arguments, thus making a very partial usage
> of this rather complex function.
>
> Besides, the bridge returned in @bridge is not refcounted, thus making this
> API unsafe when DRM bridge hotplug will be introduced.
>
> Solve both issues for the cases of calls to drm_of_find_panel_or_bridge()
> with a NULL @panel pointer by adding a new function that only looks for
> bridges (and is thus much simpler) and increments the refcount of the
> returned bridge.
>
> The new function is identical to drm_of_find_panel_or_bridge() except it:
>
> - handles bridge refcounting: uses of_drm_find_and_get_bridge() instead of
> of_drm_find_bridge() internally to return a refcounted bridge
> - is simpler to use: just takes no @panel parameter, returns the pointer
> in the return value instead of a double pointer argument
> - has a simpler implementation: it is equal to
> drm_of_find_panel_or_bridge() after removing the code that becomes dead
> when @panel == NULL
>
> Also add this function to drm_bridge.c and not drm_of.c because it returns
> bridges only.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 01/11] drm/bridge: drm_bridge_get/put(): ignore ERR_PTR
From: Dmitry Baryshkov @ 2026-04-28 11:29 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tian Tao, Xinwei Kong,
Sumit Semwal, John Stultz, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Tomi Valkeinen, Michal Simek, Hui Pu, Ian Ray, Thomas Petazzoni,
dri-devel, linux-kernel, linux-arm-msm, freedreno,
linux-arm-kernel
In-Reply-To: <20260428-drm-bridge-alloc-getput-panel_or_bridge-v2-1-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:47AM +0200, Luca Ceresoli wrote:
> Most functions returning a struct drm_bridge pointer currently return a
> valid pointer or NULL, but this restricts their ability to return an error
> code describing the error kind.
>
> In preparation to have new APIs that can return a struct drm_bridge pointer
> holding an ERR_PTR (and for those which already do) make drm_bridge_get()
> and drm_bridge_put() ignore ERR_PTR values, just like they ignore NULL
> pointers.
>
> This will avoid annoying error checking in many places and the risk of
> missing error checks.
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Link: https://lore.kernel.org/all/20260318152533.GA633439@killaraus.ideasonboard.com/
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Link: https://lore.kernel.org/all/omlnswxukeqgnatzdvooaashgkfcacjevkvbkm6xt33itgua2k@jcmzll2w6kdq/
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A
From: Marek Behún @ 2026-04-28 11:18 UTC (permalink / raw)
To: Bill Cox
Cc: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Linus Walleij, Ard Biesheuvel,
stable, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260428101430.514838-3-thorsten.blum@linux.dev>
Adding Bill Cox (waywardgeek) to the conversation.
In the meantime Nack from me on this patch.
From the original messages by Bill, it seems to me the part he was reviewing
was the ATSHA204A.
In subsequent reply [1] Bill states
While there is some evidence, there is still no convincing proof that there
is an entropy source in this device at all. There is some evidence that
Atmel has inserted a back-door. My advice is to avoid this line of parts
from Atmel for cryptographic use.
In another message Peter Gutmann asks about ATECC108 [2] and Bill replies [3]
This part uses the same language to describe the random number generator.
It is "high quality". I think that's pretty funny.
I would be interested in seeing if the new part can generate random numbers
continuously, or if it fails after it's EEPROM wears out like their other
parts. The use of an EEPROM seed is for PWN-ing your RNG, not making it
more secure.
IMO the comments from the actual reviewer are more relevant than those of the
engineer working for the company which was accused of creating low quality
/ backdoored TRNG, at least until the Atmel engineer provides some evaluation
code for the device (which they suggested they might do [4], but never did as
far as I can find).
Maybe we can instead change the ATECC quality to something like 32? Does that
even make sense?
Marek
[1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023857.html
[2] https://www.metzdowd.com/pipermail/cryptography/2014-December/023870.html
[3] https://www.metzdowd.com/pipermail/cryptography/2014-December/023879.html
[4] https://www.metzdowd.com/pipermail/cryptography/2014-December/023886.html
On Tue, Apr 28, 2026 at 12:14:32PM +0200, Thorsten Blum wrote:
> Commit 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to
> lowest possible") reduced the hwrng quality to 1 based on a review by
> Bill Cox [1]. However, despite its title, the review only tested the
> ATSHA204, not the ATSHA204A.
>
> In the same thread, Atmel engineer Landon Cox wrote "this behavior has
> been eliminated entirely"[2] in the ATSHA204A and "this problem does not
> affect the ATECC108 or the ATECC108A (or the ATSHA204A)"[3].
>
> According to the official ATSHA204A datasheet [4], the device contains a
> high-quality hardware RNG that combines its output with an internal seed
> value stored in EEPROM or SRAM to generate random numbers. The device
> also implements all security functions using SHA-256, and the driver
> uses the chip's Random command in seed-update mode.
>
> Keep 'quality = 1' for ATSHA204, but drop the explicit hwrng quality
> reduction for ATSHA204A and fall back to the hwrng core default.
>
> [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html
> [2] https://www.metzdowd.com/pipermail/cryptography/2014-December/023852.html
> [3] https://www.metzdowd.com/pipermail/cryptography/2014-December/023886.html
> [4] https://ww1.microchip.com/downloads/en/DeviceDoc/ATSHA204A-Data-Sheet-40002025A.pdf
>
> Fixes: 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to lowest possible")
> Cc: stable@vger.kernel.org
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> Changes in v2:
> - Drop the enum and dereference match data if needed as suggested by Ard
> - Keep the review comment
> - v1: https://lore.kernel.org/lkml/20260427124030.315590-3-thorsten.blum@linux.dev/
> ---
> drivers/crypto/atmel-sha204a.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index dbb39ed0cea1..a8c1b00b12f5 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -19,6 +19,12 @@
> #include <linux/workqueue.h>
> #include "atmel-i2c.h"
>
> +/*
> + * According to review by Bill Cox [1], the ATSHA204 has very low entropy.
> + * [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html
> + */
> +static const unsigned short atsha204_quality = 1;
> +
> static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
> void *areq, int status)
> {
> @@ -158,6 +164,7 @@ static const struct attribute_group atmel_sha204a_groups = {
> static int atmel_sha204a_probe(struct i2c_client *client)
> {
> struct atmel_i2c_client_priv *i2c_priv;
> + const unsigned short *quality;
> int ret;
>
> ret = atmel_i2c_probe(client);
> @@ -171,11 +178,9 @@ static int atmel_sha204a_probe(struct i2c_client *client)
> i2c_priv->hwrng.name = dev_name(&client->dev);
> i2c_priv->hwrng.read = atmel_sha204a_rng_read;
>
> - /*
> - * According to review by Bill Cox [1], this HWRNG has very low entropy.
> - * [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html
> - */
> - i2c_priv->hwrng.quality = 1;
> + quality = i2c_get_match_data(client);
> + if (quality)
> + i2c_priv->hwrng.quality = *quality;
>
> ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng);
> if (ret)
> @@ -203,14 +208,14 @@ static void atmel_sha204a_remove(struct i2c_client *client)
> }
>
> static const struct of_device_id atmel_sha204a_dt_ids[] __maybe_unused = {
> - { .compatible = "atmel,atsha204", },
> + { .compatible = "atmel,atsha204", .data = &atsha204_quality },
> { .compatible = "atmel,atsha204a", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
>
> static const struct i2c_device_id atmel_sha204a_id[] = {
> - { "atsha204" },
> + { "atsha204", (kernel_ulong_t)&atsha204_quality },
> { "atsha204a" },
> { /* sentinel */ }
> };
>
^ permalink raw reply
* Re: [QUESTION] Is the ARM SMMU v3 implementation designed to always ignore SSID when SSID_VALID == 0?
From: Joonwon Kang @ 2026-04-28 11:14 UTC (permalink / raw)
To: jpb
Cc: baolu.lu, cychu, hhchung, iommu, jgg, joonwonkang, joro,
linux-arm-kernel, linux-kernel, robin.murphy, stimim, will
In-Reply-To: <20260428090522.GA3048463@myrica>
Thanks for your prompt and insightful answer!
> Hi,
>
> On Tue, Apr 28, 2026 at 07:38:59AM +0000, Joonwon Kang wrote:
> > Hi team,
> >
> > According to the ARM SMMU v3 spec, I believe that SSID should always be
> > ignored when SSID_VALID == 0 and the current ARM SMMU v3 module
> > implementation in the kernel seems to comply with this without exception.
> > For example, when handling an event from SMMU, the implementation checks
> > SSID_VALID(SSV) first and ignores SSID accordingly. If there is any
> > exception to this rule, I believe it is a bug.
>
> Indeed
Acknowledged.
>
> > Is it true for all the current and future cases? In other words, is it
> > **mandatory** that the ARM SMMU v3 implementation ignores SSID when
> > SSID_VALID == 0? or there might be some cases where the implementation
> > needs to refer to SSID even when SSID_VALID == 0?
> >
> > Asking this question since our HW may not be able to clear SSID when
> > SSID_VALID == 0 and so there might be some garbage value in SSID at some
> > point of time(the HW will have a correct SSID when SSID_VALID == 1,
> > though). If the ARM SMMU v3 implementation is to refer to that garbage
> > value for any reason, the result would be devastating.
>
> At least according to the architecture, SubstreamID is ignored when SSV=0.
> The SMMU is allowed to propagate the garbage:
>
> 7.3 Event record
>
> * SSV: The SubstreamID validity flag
> - 0: No SubstreamID was provided with the transaction and the SubstreamID field is UNKNOWN.
>
> But the driver will ignore it.
>
> Same for PRI queue but in that case the page request wouldn't have a PASID
> TLP prefix.
Although the PRI request without PASID may cause unpleasant ATC flush with
SSV clear in this case, it does not lead to the implementation referring
to the garbage SSID. Is this understanding correct? And while this case
seems to be handled solely by the ARM SMMU v3 implementation, do you see
if there is additional care required on our device driver for this?
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH AUTOSEL 7.0-5.10] arm64: cputype: Add C1-Pro definitions
From: Mark Rutland @ 2026-04-28 11:13 UTC (permalink / raw)
To: Sasha Levin
Cc: patches, stable, Catalin Marinas, Will Deacon, James Morse,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260428104133.2858589-51-sashal@kernel.org>
On Tue, Apr 28, 2026 at 06:41:02AM -0400, Sasha Levin wrote:
> From: Catalin Marinas <catalin.marinas@arm.com>
>
> [ Upstream commit 2c99561016c591f4c3d5ad7d22a61b8726e79735 ]
>
> Add cputype definitions for C1-Pro. These will be used for errata
> detection in subsequent patches.
This definition is only needed for a workaround which is only applicable
to v6.18+ (and the downstream android16-6.12 tree).
We needn't backport this patch to v5.1.0.y unless there's something that
depends upon it.
Mark.
> These values can be found in "Table A-303: MIDR_EL1 bit descriptions" in
> issue 07 of the C1-Pro TRM:
>
> https://documentation-service.arm.com/static/6930126730f8f55a656570af
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: James Morse <james.morse@arm.com>
> Reviewed-by: Will Deacon <will@kernel.org>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>
> LLM Generated explanations, may be completely bogus:
>
> Now I have a complete picture. Let me write up the analysis.
>
> ## Analysis
>
> ### PHASE 1: COMMIT MESSAGE FORENSICS
>
> **Step 1.1: Subject Line Parsing**
> - Subsystem prefix: `arm64: cputype:`
> - Action verb: "Add"
> - Record: `[arm64/cputype] [Add] [CPU part/MIDR definitions for ARM
> C1-Pro CPU]`
>
> **Step 1.2: Tag Analysis**
> - `Acked-by: Mark Rutland <mark.rutland@arm.com>` — ARM kernel engineer
> reviewer
> - `Reviewed-by: Will Deacon <will@kernel.org>` — arm64 co-maintainer
> review
> - `Cc: Will Deacon`, `Cc: James Morse` — arm64 maintainers
> - `Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>` — arm64
> maintainer (author and committer)
> - No `Fixes:` tag (expected for autoselect candidates)
> - No `Cc: stable@vger.kernel.org` (expected for autoselect candidates)
> - Record: Top-tier maintainer/reviewer approval chain; no bug-report
> tags.
>
> **Step 1.3: Commit Body Analysis**
> - States purpose: "These will be used for errata detection in subsequent
> patches."
> - Cites ARM C1-Pro TRM (Table A-303) as the authoritative source.
> - Does NOT describe a bug, crash, or symptom.
> - Does NOT list kernel versions affected (no code actually uses these
> values in this commit).
> - Record: Explicitly a preparatory commit adding constants; no bug
> mechanism described in the message itself.
>
> **Step 1.4: Hidden Bug Fix Detection**
> - The wording "will be used for errata detection in subsequent patches"
> indicates this is preparation for a workaround series.
> - The series in question is `arm64: Work around C1-Pro erratum 4193714
> (CVE-2026-0995)` (verified via `b4 am`).
> - Record: Not a hidden fix — genuinely a prerequisite commit.
>
> ### PHASE 2: DIFF ANALYSIS
>
> **Step 2.1: Inventory**
> - Files changed: `arch/arm64/include/asm/cputype.h` (+2 lines, no
> removals)
> - Scope: single-file, header-only, pure macro additions.
> - Record: 2 lines added, 0 removed, 0 functions modified.
>
> **Step 2.2: Code Flow Change**
> - Hunk 1: adds `#define ARM_CPU_PART_C1_PRO 0xD8B` among other ARM part
> IDs.
> - Hunk 2: adds `#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM,
> ARM_CPU_PART_C1_PRO)` among other MIDR entries.
> - Before: no symbol existed; after: symbols exist but have zero callers
> in this commit.
> - Record: Pure identifier addition; no runtime behavior change.
>
> **Step 2.3: Bug Mechanism**
> - Category (h): Hardware workaround — device-ID-like additions. Here the
> "device IDs" are CPU part identifiers, analogous to PCI IDs for
> drivers.
> - Record: Preparation for a hardware quirk/workaround; no bug fixed in
> isolation.
>
> **Step 2.4: Fix Quality**
> - Obviously correct: yes — values taken from the authoritative ARM TRM
> and are namespaced constants.
> - Surgical: yes — 2 lines, no unrelated changes.
> - Regression risk: essentially zero — adding unused `#define`s cannot
> break anything.
> - Record: Trivially correct, zero regression risk.
>
> ### PHASE 3: GIT HISTORY INVESTIGATION
>
> **Step 3.1: Blame**
> - The `cputype.h` file has a long history with many similar `MIDR_*`
> additions.
> - Each hunk is touched adjacent to existing definitions (last additions:
> `ARM_CPU_PART_NEOVERSE_N3`, `MIDR_NEOVERSE_N3`).
> - Record: Following an established pattern of additions to this header.
>
> **Step 3.2: Fixes Tag**
> - No `Fixes:` tag. Not applicable.
>
> **Step 3.3: File History**
> - `git log -- arch/arm64/include/asm/cputype.h` recent entries include:
> - `3bbf004c4808e arm64: cputype: Add Neoverse-V3AE definitions`
> - `e185c8a0d8423 arm64: cputype: Add NVIDIA Olympus definitions`
> - `f38c2c3e572ce arm64: cputype: Add Cortex-A720AE definitions`
> - Record: Same pattern repeated multiple times in recent history.
>
> **Step 3.4: Author Context**
> - Author Catalin Marinas = arm64 maintainer.
> - Reviewer Will Deacon = arm64 co-maintainer.
> - Record: Top subsystem authority authored and reviewed this.
>
> **Step 3.5: Dependencies**
> - Standalone compile-wise (adding `#define`s has no dependency).
> - Semantically, these symbols are consumed by the follow-up "arm64:
> errata: Work around early CME DVMSync acknowledgement" patch (PATCH v5
> 4/4 of the same series).
> - Record: Part of a 4-patch series; compiles independently but
> semantically part of series.
>
> ### PHASE 4: MAILING LIST RESEARCH
>
> **Step 4.1: Original Submission**
> - Cover letter thread found: `https://lore.kernel.org/all/20260302165801
> .3014607-1-catalin.marinas@arm.com/` (v1, 4 patches). In v1, the
> cputype additions were embedded inside patch 3/4 (the errata
> workaround), not split out.
> - Latest revision identified via web search: v5 —
> `https://yhbt.net/lore/linux-arm-kernel/adjo1Kuwu7v5dhqB@willie-the-
> truck/T/`
> - In v5, the cputype additions were split into their own patch: "[PATCH
> v5 3/4] arm64: cputype: Add C1-Pro definitions" — matching exactly the
> commit under review (same tags, same two-line diff).
> - Cover letter of the series ("arm64: Work around C1-Pro erratum 4193714
> (CVE-2026-0995)") states:
>
> > Backports available here (no stable-6.12.y since SME is not
> supported):
> > `errata/c1-pro-erratum-4193714-stable-6.19.y`
> > `errata/c1-pro-erratum-4193714-stable-6.18.y`
> > `errata/c1-pro-erratum-4193714-android16-6.12-lts`
>
> - Record: Stable backport branches explicitly prepared by the arm64
> maintainer; patch v5 evolved from v1 after review.
>
> **Step 4.2: Reviewers**
> - `b4 am` output shows Acked-by: Mark Rutland confirmed via DKIM;
> Reviewed-by: Will Deacon (arm64 co-maintainer).
> - Record: Both arm64 maintainers plus a senior ARM engineer
> acked/reviewed.
>
> **Step 4.3: Bug Report**
> - CVE-2026-0995 assigned:
> https://developer.arm.com/documentation/111823/latest/
> - Phoronix article confirms: "Linux 7.1 Lands Workaround For Arm C1-Pro
> Erratum" (CVE-2026-0995).
> - Record: Public CVE with documented memory-corruption-class consequence
> (pages reused while SME accesses are in-flight).
>
> **Step 4.4: Related Patches**
> - 4-patch series; this is patch 3/4.
> - Patches 1/4 and 2/4: TLB infrastructure refactoring (prerequisites).
> - Patch 4/4: actual errata workaround that consumes `MIDR_C1_PRO`.
> - Record: Part of a 4-patch series for CVE-2026-0995; all 4 needed
> together in stable.
>
> **Step 4.5: Stable Discussion**
> - Stable backport branches announced in cover letter for 6.18.y and
> 6.19.y.
> - Record: Maintainer has already prepared stable backports.
>
> ### PHASE 5: CODE SEMANTIC ANALYSIS
>
> **Step 5.1: Key Functions**
> - No functions — only macro additions.
> - Record: Pure preprocessor additions.
>
> **Step 5.2/5.3/5.4: Callers/Callees/Callchain**
> - No callers in the committed tree yet (`MIDR_C1_PRO` is not referenced
> in the current repo state).
> - Intended consumer per the series: `arch/arm64/kernel/cpu_errata.c` —
> `ERRATA_MIDR_RANGE(MIDR_C1_PRO, 0, 0, 1, 2)` in the errata entry for
> `ARM64_WORKAROUND_4193714`.
> - Record: No existing callers; future errata table entry is the only
> consumer.
>
> **Step 5.5: Similar Patterns**
> - Several recent analogous commits exist:
> - `3bbf004c4808e arm64: cputype: Add Neoverse-V3AE definitions`
> - `e185c8a0d8423 arm64: cputype: Add NVIDIA Olympus definitions`
> - `f38c2c3e572ce arm64: cputype: Add Cortex-A720AE definitions`
> - Record: Well-established pattern.
>
> ### PHASE 6: CROSS-REFERENCING AND STABLE TREES
>
> **Step 6.1: Code in Stable Trees?**
> - The `cputype.h` header exists in all active stable trees (6.1.y,
> 6.6.y, 6.12.y, 6.17.y, 6.18.y, 6.19.y).
> - C1-Pro definitions themselves don't exist in any stable tree yet.
> - Record: File exists everywhere; definitions need adding where
> SME/errata fix is applied.
>
> **Step 6.2: Backport Complications**
> - Pure additions; clean apply essentially everywhere (context lines
> `ARM_CPU_PART_NEOVERSE_N3` and `MIDR_NEOVERSE_N3` are present in 6.6.y
> onward after backports, but position may shift — trivial resolution).
> - Record: Clean/trivial apply expected.
>
> **Step 6.3: Related Stable Fixes Already Present?**
> - No — no C1-Pro errata workaround exists in stable yet.
> - Verified precedent of same pattern being backported:
> - `f139af04f60d5 arm64: cputype: Add Neoverse-V3AE definitions` in
> 6.17.y
> - `6de6d315f34c5 arm64: cputype: Add Neoverse-V3AE definitions` in
> 6.12.y
> - `d9d3e9ff1e2a5 arm64: cputype: Add Neoverse-V3AE definitions` in
> 6.6.y
> - Each backport paired with its errata workaround.
> - Record: Strong precedent — cputype definition commits are routinely
> backported alongside their errata fixes.
>
> ### PHASE 7: SUBSYSTEM CONTEXT
>
> **Step 7.1: Subsystem Criticality**
> - `arch/arm64/` core CPU identification — CORE.
> - Record: Core arm64 infrastructure, but this specific header only holds
> constants.
>
> **Step 7.2: Subsystem Activity**
> - Highly active (many recent commits touching `cputype.h`).
> - Record: Active subsystem.
>
> ### PHASE 8: IMPACT AND RISK ASSESSMENT
>
> **Step 8.1: Who Is Affected**
> - In isolation: nobody — the constants are unused.
> - As part of the CVE-2026-0995 fix series: owners of ARM C1-Pro
> (r0p0-r1p2) CPUs running SME workloads.
> - Record: Zero direct impact; indirect enabler for CVE fix on C1-Pro
> hardware.
>
> **Step 8.2: Trigger Conditions**
> - This commit triggers nothing by itself.
> - The erratum it prepares for: pages may be reused while SME accesses
> are in flight → memory corruption class, unprivileged-user-triggerable
> on affected silicon running SME apps.
> - Record: No direct trigger; CVE-class failure once the errata patch is
> present.
>
> **Step 8.3: Failure Mode**
> - This commit: none.
> - Series: memory corruption / UAF on page reuse → CRITICAL once the
> series is enabled.
> - Record: Severity CRITICAL for the series; NONE for this isolated
> patch.
>
> **Step 8.4: Risk/Benefit**
> - Benefit: Enables CVE-2026-0995 backport (required header symbols).
> Without it, the errata fix won't compile.
> - Risk: Extremely low — adds two unused `#define`s; cannot regress
> anything.
> - Record: Essentially zero risk, high enabling benefit.
>
> ### PHASE 9: FINAL SYNTHESIS
>
> **Step 9.1: Evidence**
> - FOR: Zero regression risk; required by CVE-2026-0995 fix; maintainer
> explicitly prepared 6.18.y/6.19.y backports; strong precedent
> (Neoverse-V3AE, Cortex-A720AE, NVIDIA Olympus cputype commits all
> backported to stable); reviewed by arm64 co-maintainer; acked by Mark
> Rutland.
> - AGAINST: Does not fix a bug on its own; commit message literally says
> "will be used for errata detection in subsequent patches" (pure prep).
>
> **Step 9.2: Stable Rules Checklist**
> 1. Obviously correct and tested? YES (trivially — values from the ARM
> TRM; reviewed by maintainers).
> 2. Fixes a real bug? Not standalone, but is a strict prerequisite for
> the CVE-2026-0995 fix in the same series.
> 3. Important issue? Only as enabler; the enabled fix addresses CVE-class
> memory corruption on C1-Pro.
> 4. Small and contained? YES (2 lines).
> 5. No new features/APIs? Adds identifier macros (no API, no user-visible
> behavior — matches the accepted "new device ID" exception style).
> 6. Applies to stable? YES (clean apply; maintainer-prepared branches
> exist).
>
> **Step 9.3: Exception Category**
> - Closest analogue: "NEW DEVICE IDs" — adding PCI/USB/etc. IDs to
> existing drivers. Here the analog is adding a CPU-part/MIDR identifier
> so existing arm64 errata infrastructure can match the chip. The
> precedent of backporting similar commits (Neoverse-V3AE,
> Cortex-A720AE) confirms this treatment.
>
> **Step 9.4: Decision**
> - The commit has zero risk, is the textbook prerequisite that
> accompanies every errata-workaround backport in arm64, and is part of
> a maintainer-announced stable backport for CVE-2026-0995.
> - Without it, a CVE fix cannot be backported (won't compile).
> - Strong, consistent precedent in stable for this exact pattern.
>
> ## Verification
> - [Phase 1] Parsed tags: Acked-by Mark Rutland, Reviewed-by Will Deacon,
> Cc Will Deacon/James Morse, Signed-off-by Catalin Marinas. No Fixes:,
> no Cc: stable (expected).
> - [Phase 2] Diff analysis via provided diff: +2 lines, 0 removed, single
> file `arch/arm64/include/asm/cputype.h`; confirmed by reading the file
> header layout.
> - [Phase 3] `git log --oneline -- arch/arm64/include/asm/cputype.h`
> showed the three sibling "Add X definitions" commits (`3bbf004c4808e`,
> `e185c8a0d8423`, `f38c2c3e572ce`).
> - [Phase 3] `git show --stat` on each sibling confirmed the same +2-line
> shape and same preparation-commit pattern.
> - [Phase 4] `b4 am` retrieved the v1 series cover at `lore.kernel.org/al
> l/20260302165801.3014607-1-catalin.marinas@arm.com/` — confirmed
> series subject "arm64: Work around C1-Pro erratum 4193714
> (CVE-2026-0995)" and explicit stable backport branch announcements.
> - [Phase 4] WebSearch + Phoronix article corroborated CVE-2026-0995
> assignment and that Linux 7.1 merged the workaround.
> - [Phase 4] Web-fetched v5 thread at
> `yhbt.net/lore/.../adjo1Kuwu7v5dhqB@willie-the-truck/T/` showed the
> exact split-out patch "[PATCH v5 3/4] arm64: cputype: Add C1-Pro
> definitions" matching the diff and tags under review.
> - [Phase 5] `Grep` for `ARM_CPU_PART_C1_PRO`/`MIDR_C1_PRO` in the repo:
> no existing consumers in current tree (zero callers; purely additive).
> - [Phase 6] `git log stable/linux-6.17.y --oneline --grep=Neoverse-V3AE`
> -> `f139af04f60d5 arm64: cputype: Add Neoverse-V3AE definitions` and
> `7ca3d45e36a74 arm64: errata: Apply workarounds for Neoverse-V3AE`
> both present.
> - [Phase 6] `git log stable/linux-6.12.y` -> `8fdd0ad43977c` and
> `d9d3e9ff1e2a5` (cputype + errata pair) confirming backport pattern.
> - [Phase 6] `git log stable/linux-6.6.y` -> `f3ccb49186541` and
> `6de6d315f34c5` (cputype + errata pair).
> - [Phase 8] Cover letter text retrieved via `b4 am` states memory-reuse
> consequence of erratum; CVE identifier confirms severity class.
> - UNVERIFIED: I could not programmatically reach lore.kernel.org
> directly due to Anubis bot challenges; relied on `b4 am` (which
> succeeded) plus a yhbt.net mirror for the v5 thread. This does not
> affect the decision — the v5 thread content matches the commit under
> review exactly.
>
> Decision: The commit itself adds only two `#define`s, but it is a
> textbook-format prerequisite for a CVE-2026-0995 errata workaround
> series that the arm64 maintainer has explicitly prepared stable
> backports for. Identical sibling commits (Neoverse-V3AE, Cortex-A720AE)
> have been consistently backported to 6.6.y / 6.12.y / 6.17.y alongside
> their errata fixes. Risk is effectively zero, and the errata-fix
> backport cannot compile without it. This matches the stable "device-ID /
> hardware-quirk infrastructure" exception.
>
> **YES**
>
> arch/arm64/include/asm/cputype.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 08860d482e600..7b518e81dd15b 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -98,6 +98,7 @@
> #define ARM_CPU_PART_CORTEX_A725 0xD87
> #define ARM_CPU_PART_CORTEX_A720AE 0xD89
> #define ARM_CPU_PART_NEOVERSE_N3 0xD8E
> +#define ARM_CPU_PART_C1_PRO 0xD8B
>
> #define APM_CPU_PART_XGENE 0x000
> #define APM_CPU_VAR_POTENZA 0x00
> @@ -189,6 +190,7 @@
> #define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)
> #define MIDR_CORTEX_A720AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720AE)
> #define MIDR_NEOVERSE_N3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N3)
> +#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PRO)
> #define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
> #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
> #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Gary Guo @ 2026-04-28 11:10 UTC (permalink / raw)
To: Shashank Balaji, Gary Guo
Cc: Suzuki K Poulose, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Richard Cochran, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Rahul Bukte, linux-kernel,
coresight, linux-arm-kernel, driver-core, rust-for-linux,
linux-doc, Daniel Palmer, Tim Bird, linux-modules
In-Reply-To: <afABOMT_s9DvF6NY@JPC00244420>
On Tue Apr 28, 2026 at 1:37 AM BST, Shashank Balaji wrote:
> Hi Gary,
>
> On Mon, Apr 27, 2026 at 02:29:55PM +0100, Gary Guo wrote:
>> On Mon Apr 27, 2026 at 3:41 AM BST, Shashank Balaji wrote:
>> > module_kset is initialized in param_sysfs_init(), a subsys_initcall. A number
>> > of platform drivers register themselves prior to subsys_initcalls
>> > (tegra194_cbb_driver registers in a pure_initcall, for example). With an
>> > upcoming patch ("driver core: platform: set mod_name in driver registration")
>> > that sets their mod_name in struct device_driver, lookup_or_create_module_kobject()
>> > will be called for those drivers, which calls kset_find_obj(module_kset, mod_name).
>> > This causes a null deref because module_kset isn't alive yet.
>> >
>> > Fix this by initializing module_kset in do_basic_setup() before do_initcalls().
>> > Modernize the pr_warn while we're at it.
>> >
>> > Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> > Suggested-by: Gary Guo <gary@garyguo.net>
>>
>> I didn't suggest this change :)
>>
>> I suggested `pure_initcall`, which is just a one line change.
>
> Oops, sorry about the misattribution.
>
>> diff --git a/kernel/params.c b/kernel/params.c
>> index 74d620bc2521..ac088d4b09a9 100644
>> --- a/kernel/params.c
>> +++ b/kernel/params.c
>> @@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
>>
>> return 0;
>> }
>> -subsys_initcall(param_sysfs_init);
>> +pure_initcall(param_sysfs_init);
>>
>> /*
>> * param_sysfs_builtin_init - add sysfs version and parameter
>>
>> pure_initcall is level 0 so it happens before all other init calls. Does it not
>> work?
>
> tegra194_cbb_driver registers itself in a pure_initcall too. We wouldn't
> want the ordering of its registration and module_kset init to be link order
> dependent.
It's the only device driver that does this. And I don't think it's supposed to.
From documentation:
> A "pure" initcall has no dependencies on anything else, and purely
> initializes variables that couldn't be statically initialized.
I understand that given large amount of drivers registering themselves during
core/arch_initcall that there might be regressions if all of them are moved, but
surely we can demote these two specific tegra driver to core/postcore_initcall?
This will still be called earlier than init_machine call which happens during
arch_initcall.
Looks like the tegra CBB driver is just doing error logging anyway.
Best,
Gary
^ permalink raw reply
* Re: [PATCH RFC v2 0/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()
From: Sebastian Andrzej Siewior @ 2026-04-28 11:00 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Carlos O'Donell, Peter Zijlstra,
Florian Weimer, Rich Felker, Torvald Riegel, Darren Hart,
Ingo Molnar, Davidlohr Bueso, Arnd Bergmann, Liam R . Howlett,
Uros Bizjak, Thomas Weißschuh, linux-arm-kernel,
linux-kernel, linux-arch, kernel-dev
In-Reply-To: <20260424-tonyk-robust_arm-v2-0-db4e46f752cf@igalia.com>
On 2026-04-24 15:55:59 [-0300], André Almeida wrote:
> Hi folks,
Hi,
> This is my take on implementing the new vDSO for unlocking a robust futex in
> arm64. If you don't know what's that, Thomas wrote a good summary,
> including the motivation for this work and the x86 implementation:
>
> https://lore.kernel.org/lkml/878qb89g7b.ffs@tglx/
>
> There are some loose ends in my patchset so I'm sending as a RFC to ask
> some questions:
>
> - If the process is interrupted between the labels, we need to check the
> conditional flags and clear the op_pending address from the register. Using
> objdump I see that op_pending addr is being stored at x2, but I suspect that
> this isn't stable, so I need to figure out how to make sure that the address
> will always be stored in the same register.
> - So far I have implemented only the LL/SC version to make review easier, but I
> can do the LSE version as well.
I am a bit behind here. In the meantime, were you able to check it with
https://lore.kernel.org/all/20260404093939.7XgeW_54@linutronix.de/
?
Sebastian
^ permalink raw reply
* Re: [PATCH net v6] net: stmmac: Prevent NULL deref when RX memory exhausted
From: patchwork-bot+netdevbpf @ 2026-04-28 10:50 UTC (permalink / raw)
To: Sam Edwards
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, ovidiu.panait.rb,
vladimir.oltean, baruch, fancer.lancer, peppe.cavallaro, netdev,
linux-stm32, linux-arm-kernel, linux-kernel, CFSworks, stable,
linux
In-Reply-To: <20260422044503.5349-1-CFSworks@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 21 Apr 2026 21:45:03 -0700 you wrote:
> The CPU receives frames from the MAC through conventional DMA: the CPU
> allocates buffers for the MAC, then the MAC fills them and returns
> ownership to the CPU. For each hardware RX queue, the CPU and MAC
> coordinate through a shared ring array of DMA descriptors: one
> descriptor per DMA buffer. Each descriptor includes the buffer's
> physical address and a status flag ("OWN") indicating which side owns
> the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set
> the flag and the MAC is only allowed to clear it, and both must move
> through the ring in sequence: thus the ring is used for both
> "submissions" and "completions."
>
> [...]
Here is the summary with links:
- [net,v6] net: stmmac: Prevent NULL deref when RX memory exhausted
https://git.kernel.org/netdev/net/c/0bb05e6adfa9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: common-v1: Directly modify registers to set GPIO direction
From: Linus Walleij @ 2026-04-28 10:48 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260427061720.2393355-1-wenst@chromium.org>
On Mon, Apr 27, 2026 at 8:17 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
> the pinctrl mutex. This causes a gpiochip operations to need to sleep.
> Worse yet, the .can_sleep field in the gpiochip is not set. This causes
> the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
> whether it can use a spinlock or needs a mutex. In this case, it ends
> up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
> takes a mutex. This causes a huge warning.
>
> Since the Mediatek hardware has separate clear/set registers, there is
> no risk of clobbering other bits like with a read-modify-write pattern.
> Switch to directly setting the GPIO direction register bits to avoid
> the mutex.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Here you need to at least delete the assignment of mtk_pmx_gpio_set_direction()
from:
static const struct pinmux_ops mtk_pmx_ops = {
.get_functions_count = mtk_pmx_get_funcs_cnt,
.get_function_name = mtk_pmx_get_func_name,
.get_function_groups = mtk_pmx_get_func_groups,
.set_mux = mtk_pmx_set_mux,
.gpio_set_direction = mtk_pmx_gpio_set_direction,
^ Here, it should no longer be used, right?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: paris: Directly modify registers to set GPIO direction
From: Linus Walleij @ 2026-04-28 10:44 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260427021021.2049015-1-wenst@chromium.org>
On Mon, Apr 27, 2026 at 4:10 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
> the pinctrl mutex. This causes a gpiochip operations to need to sleep.
> Worse yet, the .can_sleep field in the gpiochip is not set. This causes
> the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
> whether it can use a spinlock or needs a mutex. In this case, it ends
> up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
> takes a mutex. This causes a huge warning.
>
> While this class of Mediatek hardware does not have separate clear/set
> registers, the pinctrl context has a spinlock that is taken whenever
> a register read-modify-write is done.
>
> Switch to directly setting the GPIO direction register bits to avoid
> the mutex.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
You are essentially decoupling the pin control back-end from
the GPIO front-end, can you try to do this a more friendly way
that doesn't wrangle registers out of the pin controller like this?
If you insist on doing this, you also need to DELETE the pin
control back-end function
mtk_pinmux_gpio_set_direction(), which is what gets called.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.10] arm64: cputype: Add C1-Pro definitions
From: Sasha Levin @ 2026-04-28 10:41 UTC (permalink / raw)
To: patches, stable
Cc: Catalin Marinas, Mark Rutland, Will Deacon, James Morse,
Sasha Levin, linux-arm-kernel, linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Catalin Marinas <catalin.marinas@arm.com>
[ Upstream commit 2c99561016c591f4c3d5ad7d22a61b8726e79735 ]
Add cputype definitions for C1-Pro. These will be used for errata
detection in subsequent patches.
These values can be found in "Table A-303: MIDR_EL1 bit descriptions" in
issue 07 of the C1-Pro TRM:
https://documentation-service.arm.com/static/6930126730f8f55a656570af
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: James Morse <james.morse@arm.com>
Reviewed-by: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have a complete picture. Let me write up the analysis.
## Analysis
### PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line Parsing**
- Subsystem prefix: `arm64: cputype:`
- Action verb: "Add"
- Record: `[arm64/cputype] [Add] [CPU part/MIDR definitions for ARM
C1-Pro CPU]`
**Step 1.2: Tag Analysis**
- `Acked-by: Mark Rutland <mark.rutland@arm.com>` — ARM kernel engineer
reviewer
- `Reviewed-by: Will Deacon <will@kernel.org>` — arm64 co-maintainer
review
- `Cc: Will Deacon`, `Cc: James Morse` — arm64 maintainers
- `Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>` — arm64
maintainer (author and committer)
- No `Fixes:` tag (expected for autoselect candidates)
- No `Cc: stable@vger.kernel.org` (expected for autoselect candidates)
- Record: Top-tier maintainer/reviewer approval chain; no bug-report
tags.
**Step 1.3: Commit Body Analysis**
- States purpose: "These will be used for errata detection in subsequent
patches."
- Cites ARM C1-Pro TRM (Table A-303) as the authoritative source.
- Does NOT describe a bug, crash, or symptom.
- Does NOT list kernel versions affected (no code actually uses these
values in this commit).
- Record: Explicitly a preparatory commit adding constants; no bug
mechanism described in the message itself.
**Step 1.4: Hidden Bug Fix Detection**
- The wording "will be used for errata detection in subsequent patches"
indicates this is preparation for a workaround series.
- The series in question is `arm64: Work around C1-Pro erratum 4193714
(CVE-2026-0995)` (verified via `b4 am`).
- Record: Not a hidden fix — genuinely a prerequisite commit.
### PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Files changed: `arch/arm64/include/asm/cputype.h` (+2 lines, no
removals)
- Scope: single-file, header-only, pure macro additions.
- Record: 2 lines added, 0 removed, 0 functions modified.
**Step 2.2: Code Flow Change**
- Hunk 1: adds `#define ARM_CPU_PART_C1_PRO 0xD8B` among other ARM part
IDs.
- Hunk 2: adds `#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM,
ARM_CPU_PART_C1_PRO)` among other MIDR entries.
- Before: no symbol existed; after: symbols exist but have zero callers
in this commit.
- Record: Pure identifier addition; no runtime behavior change.
**Step 2.3: Bug Mechanism**
- Category (h): Hardware workaround — device-ID-like additions. Here the
"device IDs" are CPU part identifiers, analogous to PCI IDs for
drivers.
- Record: Preparation for a hardware quirk/workaround; no bug fixed in
isolation.
**Step 2.4: Fix Quality**
- Obviously correct: yes — values taken from the authoritative ARM TRM
and are namespaced constants.
- Surgical: yes — 2 lines, no unrelated changes.
- Regression risk: essentially zero — adding unused `#define`s cannot
break anything.
- Record: Trivially correct, zero regression risk.
### PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- The `cputype.h` file has a long history with many similar `MIDR_*`
additions.
- Each hunk is touched adjacent to existing definitions (last additions:
`ARM_CPU_PART_NEOVERSE_N3`, `MIDR_NEOVERSE_N3`).
- Record: Following an established pattern of additions to this header.
**Step 3.2: Fixes Tag**
- No `Fixes:` tag. Not applicable.
**Step 3.3: File History**
- `git log -- arch/arm64/include/asm/cputype.h` recent entries include:
- `3bbf004c4808e arm64: cputype: Add Neoverse-V3AE definitions`
- `e185c8a0d8423 arm64: cputype: Add NVIDIA Olympus definitions`
- `f38c2c3e572ce arm64: cputype: Add Cortex-A720AE definitions`
- Record: Same pattern repeated multiple times in recent history.
**Step 3.4: Author Context**
- Author Catalin Marinas = arm64 maintainer.
- Reviewer Will Deacon = arm64 co-maintainer.
- Record: Top subsystem authority authored and reviewed this.
**Step 3.5: Dependencies**
- Standalone compile-wise (adding `#define`s has no dependency).
- Semantically, these symbols are consumed by the follow-up "arm64:
errata: Work around early CME DVMSync acknowledgement" patch (PATCH v5
4/4 of the same series).
- Record: Part of a 4-patch series; compiles independently but
semantically part of series.
### PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original Submission**
- Cover letter thread found: `https://lore.kernel.org/all/20260302165801
.3014607-1-catalin.marinas@arm.com/` (v1, 4 patches). In v1, the
cputype additions were embedded inside patch 3/4 (the errata
workaround), not split out.
- Latest revision identified via web search: v5 —
`https://yhbt.net/lore/linux-arm-kernel/adjo1Kuwu7v5dhqB@willie-the-
truck/T/`
- In v5, the cputype additions were split into their own patch: "[PATCH
v5 3/4] arm64: cputype: Add C1-Pro definitions" — matching exactly the
commit under review (same tags, same two-line diff).
- Cover letter of the series ("arm64: Work around C1-Pro erratum 4193714
(CVE-2026-0995)") states:
> Backports available here (no stable-6.12.y since SME is not
supported):
> `errata/c1-pro-erratum-4193714-stable-6.19.y`
> `errata/c1-pro-erratum-4193714-stable-6.18.y`
> `errata/c1-pro-erratum-4193714-android16-6.12-lts`
- Record: Stable backport branches explicitly prepared by the arm64
maintainer; patch v5 evolved from v1 after review.
**Step 4.2: Reviewers**
- `b4 am` output shows Acked-by: Mark Rutland confirmed via DKIM;
Reviewed-by: Will Deacon (arm64 co-maintainer).
- Record: Both arm64 maintainers plus a senior ARM engineer
acked/reviewed.
**Step 4.3: Bug Report**
- CVE-2026-0995 assigned:
https://developer.arm.com/documentation/111823/latest/
- Phoronix article confirms: "Linux 7.1 Lands Workaround For Arm C1-Pro
Erratum" (CVE-2026-0995).
- Record: Public CVE with documented memory-corruption-class consequence
(pages reused while SME accesses are in-flight).
**Step 4.4: Related Patches**
- 4-patch series; this is patch 3/4.
- Patches 1/4 and 2/4: TLB infrastructure refactoring (prerequisites).
- Patch 4/4: actual errata workaround that consumes `MIDR_C1_PRO`.
- Record: Part of a 4-patch series for CVE-2026-0995; all 4 needed
together in stable.
**Step 4.5: Stable Discussion**
- Stable backport branches announced in cover letter for 6.18.y and
6.19.y.
- Record: Maintainer has already prepared stable backports.
### PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Key Functions**
- No functions — only macro additions.
- Record: Pure preprocessor additions.
**Step 5.2/5.3/5.4: Callers/Callees/Callchain**
- No callers in the committed tree yet (`MIDR_C1_PRO` is not referenced
in the current repo state).
- Intended consumer per the series: `arch/arm64/kernel/cpu_errata.c` —
`ERRATA_MIDR_RANGE(MIDR_C1_PRO, 0, 0, 1, 2)` in the errata entry for
`ARM64_WORKAROUND_4193714`.
- Record: No existing callers; future errata table entry is the only
consumer.
**Step 5.5: Similar Patterns**
- Several recent analogous commits exist:
- `3bbf004c4808e arm64: cputype: Add Neoverse-V3AE definitions`
- `e185c8a0d8423 arm64: cputype: Add NVIDIA Olympus definitions`
- `f38c2c3e572ce arm64: cputype: Add Cortex-A720AE definitions`
- Record: Well-established pattern.
### PHASE 6: CROSS-REFERENCING AND STABLE TREES
**Step 6.1: Code in Stable Trees?**
- The `cputype.h` header exists in all active stable trees (6.1.y,
6.6.y, 6.12.y, 6.17.y, 6.18.y, 6.19.y).
- C1-Pro definitions themselves don't exist in any stable tree yet.
- Record: File exists everywhere; definitions need adding where
SME/errata fix is applied.
**Step 6.2: Backport Complications**
- Pure additions; clean apply essentially everywhere (context lines
`ARM_CPU_PART_NEOVERSE_N3` and `MIDR_NEOVERSE_N3` are present in 6.6.y
onward after backports, but position may shift — trivial resolution).
- Record: Clean/trivial apply expected.
**Step 6.3: Related Stable Fixes Already Present?**
- No — no C1-Pro errata workaround exists in stable yet.
- Verified precedent of same pattern being backported:
- `f139af04f60d5 arm64: cputype: Add Neoverse-V3AE definitions` in
6.17.y
- `6de6d315f34c5 arm64: cputype: Add Neoverse-V3AE definitions` in
6.12.y
- `d9d3e9ff1e2a5 arm64: cputype: Add Neoverse-V3AE definitions` in
6.6.y
- Each backport paired with its errata workaround.
- Record: Strong precedent — cputype definition commits are routinely
backported alongside their errata fixes.
### PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem Criticality**
- `arch/arm64/` core CPU identification — CORE.
- Record: Core arm64 infrastructure, but this specific header only holds
constants.
**Step 7.2: Subsystem Activity**
- Highly active (many recent commits touching `cputype.h`).
- Record: Active subsystem.
### PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Who Is Affected**
- In isolation: nobody — the constants are unused.
- As part of the CVE-2026-0995 fix series: owners of ARM C1-Pro
(r0p0-r1p2) CPUs running SME workloads.
- Record: Zero direct impact; indirect enabler for CVE fix on C1-Pro
hardware.
**Step 8.2: Trigger Conditions**
- This commit triggers nothing by itself.
- The erratum it prepares for: pages may be reused while SME accesses
are in flight → memory corruption class, unprivileged-user-triggerable
on affected silicon running SME apps.
- Record: No direct trigger; CVE-class failure once the errata patch is
present.
**Step 8.3: Failure Mode**
- This commit: none.
- Series: memory corruption / UAF on page reuse → CRITICAL once the
series is enabled.
- Record: Severity CRITICAL for the series; NONE for this isolated
patch.
**Step 8.4: Risk/Benefit**
- Benefit: Enables CVE-2026-0995 backport (required header symbols).
Without it, the errata fix won't compile.
- Risk: Extremely low — adds two unused `#define`s; cannot regress
anything.
- Record: Essentially zero risk, high enabling benefit.
### PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
- FOR: Zero regression risk; required by CVE-2026-0995 fix; maintainer
explicitly prepared 6.18.y/6.19.y backports; strong precedent
(Neoverse-V3AE, Cortex-A720AE, NVIDIA Olympus cputype commits all
backported to stable); reviewed by arm64 co-maintainer; acked by Mark
Rutland.
- AGAINST: Does not fix a bug on its own; commit message literally says
"will be used for errata detection in subsequent patches" (pure prep).
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? YES (trivially — values from the ARM
TRM; reviewed by maintainers).
2. Fixes a real bug? Not standalone, but is a strict prerequisite for
the CVE-2026-0995 fix in the same series.
3. Important issue? Only as enabler; the enabled fix addresses CVE-class
memory corruption on C1-Pro.
4. Small and contained? YES (2 lines).
5. No new features/APIs? Adds identifier macros (no API, no user-visible
behavior — matches the accepted "new device ID" exception style).
6. Applies to stable? YES (clean apply; maintainer-prepared branches
exist).
**Step 9.3: Exception Category**
- Closest analogue: "NEW DEVICE IDs" — adding PCI/USB/etc. IDs to
existing drivers. Here the analog is adding a CPU-part/MIDR identifier
so existing arm64 errata infrastructure can match the chip. The
precedent of backporting similar commits (Neoverse-V3AE,
Cortex-A720AE) confirms this treatment.
**Step 9.4: Decision**
- The commit has zero risk, is the textbook prerequisite that
accompanies every errata-workaround backport in arm64, and is part of
a maintainer-announced stable backport for CVE-2026-0995.
- Without it, a CVE fix cannot be backported (won't compile).
- Strong, consistent precedent in stable for this exact pattern.
## Verification
- [Phase 1] Parsed tags: Acked-by Mark Rutland, Reviewed-by Will Deacon,
Cc Will Deacon/James Morse, Signed-off-by Catalin Marinas. No Fixes:,
no Cc: stable (expected).
- [Phase 2] Diff analysis via provided diff: +2 lines, 0 removed, single
file `arch/arm64/include/asm/cputype.h`; confirmed by reading the file
header layout.
- [Phase 3] `git log --oneline -- arch/arm64/include/asm/cputype.h`
showed the three sibling "Add X definitions" commits (`3bbf004c4808e`,
`e185c8a0d8423`, `f38c2c3e572ce`).
- [Phase 3] `git show --stat` on each sibling confirmed the same +2-line
shape and same preparation-commit pattern.
- [Phase 4] `b4 am` retrieved the v1 series cover at `lore.kernel.org/al
l/20260302165801.3014607-1-catalin.marinas@arm.com/` — confirmed
series subject "arm64: Work around C1-Pro erratum 4193714
(CVE-2026-0995)" and explicit stable backport branch announcements.
- [Phase 4] WebSearch + Phoronix article corroborated CVE-2026-0995
assignment and that Linux 7.1 merged the workaround.
- [Phase 4] Web-fetched v5 thread at
`yhbt.net/lore/.../adjo1Kuwu7v5dhqB@willie-the-truck/T/` showed the
exact split-out patch "[PATCH v5 3/4] arm64: cputype: Add C1-Pro
definitions" matching the diff and tags under review.
- [Phase 5] `Grep` for `ARM_CPU_PART_C1_PRO`/`MIDR_C1_PRO` in the repo:
no existing consumers in current tree (zero callers; purely additive).
- [Phase 6] `git log stable/linux-6.17.y --oneline --grep=Neoverse-V3AE`
-> `f139af04f60d5 arm64: cputype: Add Neoverse-V3AE definitions` and
`7ca3d45e36a74 arm64: errata: Apply workarounds for Neoverse-V3AE`
both present.
- [Phase 6] `git log stable/linux-6.12.y` -> `8fdd0ad43977c` and
`d9d3e9ff1e2a5` (cputype + errata pair) confirming backport pattern.
- [Phase 6] `git log stable/linux-6.6.y` -> `f3ccb49186541` and
`6de6d315f34c5` (cputype + errata pair).
- [Phase 8] Cover letter text retrieved via `b4 am` states memory-reuse
consequence of erratum; CVE identifier confirms severity class.
- UNVERIFIED: I could not programmatically reach lore.kernel.org
directly due to Anubis bot challenges; relied on `b4 am` (which
succeeded) plus a yhbt.net mirror for the v5 thread. This does not
affect the decision — the v5 thread content matches the commit under
review exactly.
Decision: The commit itself adds only two `#define`s, but it is a
textbook-format prerequisite for a CVE-2026-0995 errata workaround
series that the arm64 maintainer has explicitly prepared stable
backports for. Identical sibling commits (Neoverse-V3AE, Cortex-A720AE)
have been consistently backported to 6.6.y / 6.12.y / 6.17.y alongside
their errata fixes. Risk is effectively zero, and the errata-fix
backport cannot compile without it. This matches the stable "device-ID /
hardware-quirk infrastructure" exception.
**YES**
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 08860d482e600..7b518e81dd15b 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -98,6 +98,7 @@
#define ARM_CPU_PART_CORTEX_A725 0xD87
#define ARM_CPU_PART_CORTEX_A720AE 0xD89
#define ARM_CPU_PART_NEOVERSE_N3 0xD8E
+#define ARM_CPU_PART_C1_PRO 0xD8B
#define APM_CPU_PART_XGENE 0x000
#define APM_CPU_VAR_POTENZA 0x00
@@ -189,6 +190,7 @@
#define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)
#define MIDR_CORTEX_A720AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720AE)
#define MIDR_NEOVERSE_N3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N3)
+#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PRO)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] tty: serial: imx: keep dma request disabled before dma transfer setup
From: Sasha Levin @ 2026-04-28 10:40 UTC (permalink / raw)
To: patches, stable
Cc: Robin Gong, Sherry Sun, Greg Kroah-Hartman, Sasha Levin,
jirislaby, shawnguo, linux-kernel, linux-serial, linux-arm-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Robin Gong <yibin.gong@nxp.com>
[ Upstream commit 74e0c9f0528bcd597cb1299a027d7be27d1c27d9 ]
Since sdma hardware configure postpone to transfer phase, have to
disable dma request before dma transfer setup because there is a
hardware limitation on sdma event enable(ENBLn) as below.
Refer SDMA 2.6.28 Channel Enable RAM (SDMAARMx_CHNENBLn) section:
"It is thus essential for the Arm platform to program them before any
DMA request is triggered to the SDMA, otherwise an unpredictable
combination of channels may be started."
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Link: https://patch.msgid.link/20260312094526.297348-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to provide the full analysis.
## Analysis: tty: serial: imx: keep dma request disabled before dma
transfer setup
### PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject line**
Record: `tty: serial: imx:` subsystem, action verb "keep" (implies
correcting improper state), one-line summary: "ensure UART DMA request
stays disabled until SDMA channel is fully configured."
**Step 1.2: Tags**
Record:
- Signed-off-by: Robin Gong (author, NXP), Sherry Sun (submitter, NXP),
Greg Kroah-Hartman (tty maintainer)
- Link:
https://patch.msgid.link/20260312094526.297348-1-sherry.sun@nxp.com
- NO Fixes: tag (expected)
- NO Cc: stable tag (expected)
- NO Reported-by/Tested-by/Reviewed-by
**Step 1.3: Commit body analysis**
Record: Commit explains a hardware limitation documented in the SDMA
reference manual (section 2.6.28, "Channel Enable RAM /
SDMAARMx_CHNENBLn"). When UART asserts a DMA request before the SDMA
channel script has been properly configured, "unpredictable combination
of channels may be started." No stack trace/reproducer, but cites an
authoritative NXP/Freescale hardware reference manual. Root cause: SDMA
configuration is postponed to the transfer phase, so starting the UART
DMA request before `dma_async_issue_pending()` on the corresponding
channel is a hardware-level ordering violation.
**Step 1.4: Hidden bug fix detection**
Record: Yes — "keep disabled before setup" is a classic disguised bug
fix. This corrects an improper ordering that leads to undefined hardware
behavior.
### PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: 1 file (`drivers/tty/serial/imx.c`), 3 lines modified + 2
comment lines changed, 1 line added net. Two functions touched:
`imx_uart_enable_dma()` and `imx_uart_startup()`. Scope: single-file
surgical fix.
**Step 2.2: Code flow change**
```1438:1451:drivers/tty/serial/imx.c
static void imx_uart_enable_dma(struct imx_port *sport)
{
u32 ucr1;
imx_uart_setup_ufcr(sport, TXTL_DMA, RXTL_DMA);
/* set UCR1 */
ucr1 = imx_uart_readl(sport, UCR1);
ucr1 |= UCR1_RXDMAEN | UCR1_TXDMAEN | UCR1_ATDMAEN;
imx_uart_writel(sport, ucr1, UCR1);
sport->dma_is_enabled = 1;
}
```
Record:
- Hunk 1 (`imx_uart_enable_dma`): BEFORE sets `UCR1_RXDMAEN |
UCR1_TXDMAEN | UCR1_ATDMAEN` atomically; AFTER sets only `UCR1_RXDMAEN
| UCR1_ATDMAEN` (TXDMAEN now enabled later in `imx_uart_dma_tx`).
- Hunk 2 (`imx_uart_startup`): BEFORE calls `imx_uart_enable_dma()` THEN
`imx_uart_start_rx_dma()`; AFTER calls `imx_uart_start_rx_dma()` THEN
`imx_uart_enable_dma()`. The RX DMA channel is configured/submitted
BEFORE the UART starts asserting DMA requests.
**Step 2.3: Bug mechanism**
Record: Category (h) Hardware workaround + ordering/correctness fix. The
mechanism: UART asserting DMA requests on UCR1 before SDMA has a valid
descriptor/channel configuration can trigger an ill-defined SDMA
channel, leading to corrupted/misrouted transfers. Confirmed by
verifying that `imx_uart_dma_tx()` at line 662-664 already sets
`UCR1_TXDMAEN` just before
`dmaengine_submit()/dma_async_issue_pending()` — so removing it from
`imx_uart_enable_dma()` is safe (TXDMAEN will still be set when actually
needed).
**Step 2.4: Fix quality**
Record: Obviously correct. The fix preserves exact functionality
(TXDMAEN still ends up set before TX transfer, RX DMA still starts
before UART DMA requests flow). No regression risk in the fix itself —
just reorders two well-defined function calls and defers one register
bit. No locking changes, no API changes.
### PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
Record: `imx_uart_enable_dma` and UART DMA support originated from
commit `b4cdc8f61beb2` ("serial: imx: add DMA support for imx6q", July
2013). The `temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN` line was
set together from day one — the buggy ordering has been present since
2013 (kernel v3.11). All active stable trees inherit it.
**Step 3.2: Fixes: tag** — Not present. The bug is a long-standing
hardware sequencing violation.
**Step 3.3: Related file changes**
Record: Recent changes to `drivers/tty/serial/imx.c` (wake event
reporting, hrtimer, nbcon, etc.) do not touch the DMA init/enable paths
— no conflicts expected.
**Step 3.4: Author's relationship**
Record: Robin Gong is an NXP engineer and has authored the equivalent
fix in the SDMA driver itself (commit `107d06441b709` in 2018) which
changed where `sdma_event_enable()` is called. He's an authority on SDMA
hardware semantics.
**Step 3.5: Dependencies**
Record: No prerequisite commits needed. The fix depends only on
`imx_uart_dma_tx()` already containing `ucr1 |= UCR1_TXDMAEN`, which I
verified exists in v5.4, v5.10, v5.15, v6.1, v6.6, v6.12.
### PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original submission**
Record: `b4 dig -c 74e0c9f0528bc` found
https://lore.kernel.org/all/20260312094526.297348-1-sherry.sun@nxp.com/.
Single-revision v1 patch. Thread contains only the patch submission — no
review replies, no NAKs, no stable nominations. Greg KH applied it
directly.
**Step 4.2: Recipients**
Record: Sent to gregkh, jirislaby (tty maintainers), Frank.Li@nxp.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam, tglx, mingo.
Appropriate maintainers CC'd.
**Step 4.3: Bug report** — No explicit report linked; the fix cites the
SoC reference manual.
**Step 4.4: Related series (CRITICAL)**
Record: The SAME hardware-sequencing fix was previously applied to the
SPI driver in commit `86d57d9c07d54` ("spi: imx: keep dma request
disabled before dma transfer setup", Oct 2025). That SPI fix has already
been backported to stable branches 5.10, 5.15, 6.1, 6.6, 6.12, and 6.17
(verified via `git branch --contains`). This establishes a clear
precedent that the stable maintainers consider this exact SDMA-ordering
issue worth backporting.
**Step 4.5: Stable ML** — The SPI equivalent already flowed into stable
via AUTOSEL.
### PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1-5.4: Call chain**
Record: `imx_uart_enable_dma()` is called exclusively from
`imx_uart_startup()`. `imx_uart_startup()` is the `uart_ops::startup`
callback, invoked every time a UART port is opened. This is a common,
user-triggerable path — every process opening `/dev/ttymxcN` hits it. So
the buggy sequencing is exercised on every UART open with DMA enabled.
**Step 5.5: Similar patterns**
Record: The same bug pattern exists in `drivers/spi/spi-imx.c` and was
fixed by commit `86d57d9c07d54`, already backported broadly. The SDMA
driver itself carries a comment "Set ENBLn earlier to make sure dma
request triggered after that" (`drivers/dma/imx-sdma.c:1859`),
corroborating that this ordering requirement is well-established
hardware lore.
### PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Buggy code exists in stable?**
Record: YES. Verified `imx_uart_enable_dma()` and the buggy
`imx_uart_enable_dma(); imx_uart_start_rx_dma();` ordering is present in
v5.4, v5.10, v5.15, v6.1, v6.6, v6.12. `imx_uart_dma_tx()` also already
contains the `ucr1 |= UCR1_TXDMAEN` statement (the dependency for the
fix).
**Step 6.2: Backport complications**
Record: Patch applies CLEANLY (`git apply --check` succeeded with no
output) against v5.4, v5.10, v5.15, v6.1, v6.6, v6.12. No backport
adjustments needed.
**Step 6.3: Related fixes already in stable**
Record: No — this particular fix has not yet flowed to stable for the
UART driver. The sibling SPI fix is already in stable trees.
### PHASE 7: SUBSYSTEM CONTEXT
Record: `drivers/tty/serial/imx.c` — IMX UART driver. Used by millions
of embedded/industrial iMX-based systems. Criticality: IMPORTANT
(driver-specific but widely deployed). Active subsystem (recent
wakeup/RXTL fixes show ongoing maintenance).
### PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected users**
Record: iMX SoC users (iMX6, iMX7, iMX8, iMX9 families) using UART with
DMA (typical when hardware flow control is enabled for high-throughput
serial communication).
**Step 8.2: Triggering conditions**
Record: Every time a DMA-capable iMX UART port is opened (uart startup
path). Whether the race window actually causes misbehavior depends on:
whether the TX FIFO happens to fall below the watermark immediately
after TXDMAEN is set but before a descriptor is prepared; whether the RX
line has incoming data arriving before start_rx_dma finishes. Easily
reachable on active serial links.
**Step 8.3: Failure mode**
Record: "unpredictable combination of channels may be started" per SDMA
hardware docs. In practice this can manifest as: lost/corrupted UART
data, spurious channel activation that may corrupt memory (SDMA writing
to stale addresses), or flaky DMA behavior that's hard to debug.
Severity: HIGH (data integrity + potential silent memory corruption on a
DMA engine).
**Step 8.4: Risk-benefit**
Record: BENEFIT: prevents documented hardware misbehavior on a widely-
deployed SoC family; consistency with SPI driver fix already in stable.
RISK: very low — 3-line reordering, no new locks/APIs, dependency
(TXDMAEN in dma_tx) verified present in all stable trees, patch applies
cleanly, identical fix pattern already tested in production via SPI
backport.
### PHASE 9: FINAL SYNTHESIS
**Evidence FOR:** Fixes documented SoC hardware limitation; tiny
surgical change; author is SDMA subject-matter expert; same fix pattern
already accepted into stable (5.10→6.17) for spi-imx; code path is very
common (uart_startup); patch applies cleanly to all stable trees; falls
into the "Hardware Quirk/Workaround" exception category.
**Evidence AGAINST:** No explicit Reported-by/Tested-by (but the fix
cites authoritative SoC docs); no explicit stable nomination (but
absence is expected).
**Stable rules checklist:**
1. Obviously correct and tested? YES — TXDMAEN placement verified,
reorder is semantically equivalent.
2. Fixes a real bug? YES — documented hardware sequencing violation.
3. Important issue? YES — data corruption / unpredictable DMA behavior.
4. Small and contained? YES — 3 lines of actual code change.
5. No new features? YES — pure correctness/reorder fix.
6. Applies to stable trees? YES — clean apply verified.
**Exception category:** Hardware workaround for SDMA ENBLn sequencing
requirement.
### Verification
- [Phase 1] Parsed tags: no Fixes/Cc-stable/Reported-by; Link to lore
verified
- [Phase 2] Diff shows `imx_uart_enable_dma` drops TXDMAEN;
`imx_uart_startup` swaps call order of `start_rx_dma` and `enable_dma`
- [Phase 2] Verified `imx_uart_dma_tx()` in current tree and all stable
trees contains `ucr1 |= UCR1_TXDMAEN` at lines
~658/657/666/660/682/637 respectively — the fix's dependency is met
- [Phase 3] `git log -S"imx_enable_dma"` identified original DMA commit
`b4cdc8f61beb2` (Jul 2013)
- [Phase 3] `git blame` on `sdma_event_enable` call in imx-sdma.c
corroborates the hardware ordering requirement
- [Phase 4] `b4 dig -c 74e0c9f0528bc` found lore URL; `-a` shows only
v1; mbox inspection shows no replies/NAKs
- [Phase 4] `b4 dig -c 86d57d9c07d54` for sibling SPI fix confirmed it
went through review (Frank Li, Mark Brown)
- [Phase 4] `git branch --contains` for multiple SPI backport commits
confirmed backport to 5.10/5.15/6.1/6.6/6.12/6.17
- [Phase 5] Confirmed `imx_uart_enable_dma` has a single caller
(`imx_uart_startup`) via `Grep`
- [Phase 6] `git show vX:drivers/tty/serial/imx.c` for v5.4, v5.10,
v5.15, v6.1, v6.6, v6.12 all show identical buggy ordering
- [Phase 6] `git apply --check /tmp/fix.patch` succeeded on v5.4, v5.10,
v5.15, v6.1, v6.6, v6.12 (no output = success)
- [Phase 8] Failure mode per SoC reference manual — cited directly in
commit message
- UNVERIFIED: No user bug report could be located; severity inferred
from SoC documentation only. The exact race-window probability on a
specific board is not quantified.
Small, well-contained hardware-sequencing fix; same issue already
accepted into stable trees for the sister SPI driver; dependency
verified; applies cleanly. Meets all stable criteria.
**YES**
drivers/tty/serial/imx.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index c488e5d372ffd..251a50c8aa387 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1442,9 +1442,9 @@ static void imx_uart_enable_dma(struct imx_port *sport)
imx_uart_setup_ufcr(sport, TXTL_DMA, RXTL_DMA);
- /* set UCR1 */
+ /* set UCR1 except TXDMAEN which would be enabled in imx_uart_dma_tx */
ucr1 = imx_uart_readl(sport, UCR1);
- ucr1 |= UCR1_RXDMAEN | UCR1_TXDMAEN | UCR1_ATDMAEN;
+ ucr1 |= UCR1_RXDMAEN | UCR1_ATDMAEN;
imx_uart_writel(sport, ucr1, UCR1);
sport->dma_is_enabled = 1;
@@ -1567,8 +1567,9 @@ static int imx_uart_startup(struct uart_port *port)
imx_uart_enable_ms(&sport->port);
if (dma_is_inited) {
- imx_uart_enable_dma(sport);
+ /* Note: enable dma request after transfer start! */
imx_uart_start_rx_dma(sport);
+ imx_uart_enable_dma(sport);
} else {
ucr1 = imx_uart_readl(sport, UCR1);
ucr1 |= UCR1_RRDYEN;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] dt-bindings: arm64: add Marvell 7k COMe boards
From: Sasha Levin @ 2026-04-28 10:40 UTC (permalink / raw)
To: patches, stable
Cc: Elad Nachman, Rob Herring (Arm), Gregory CLEMENT, Sasha Levin,
andrew, sebastian.hesselbarth, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Elad Nachman <enachman@marvell.com>
[ Upstream commit 283822a64d6bd9aca55b5e2718bc63e9815b443d ]
Add dt bindings for:
Armada 7020 COM Express CPU module
Falcon DB-98CX85x0 COM Express type 7 Carrier board
Falcon DB-98CX85x0 COM Express type 7 Carrier board
with an Armada 7020 COM Express CPU module
Signed-off-by: Elad Nachman <enachman@marvell.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Based on my investigation, I have enough information to complete the
analysis.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
Record: Subsystem `dt-bindings: arm64`, action verb `add`, summary: "Add
DT binding descriptions for the Marvell Falcon DB-98CX85x0 COM Express
carrier board and Armada 7020 CPU module."
**Step 1.2: Tags**
Record: `Signed-off-by: Elad Nachman` (author), `Acked-by: Rob Herring
(Arm) <robh@kernel.org>` (DT maintainer), `Signed-off-by: Gregory
CLEMENT <gregory.clement@bootlin.com>` (mvebu maintainer). No `Fixes:`,
no `Cc: stable`, no `Reported-by:`, no `Link:`.
**Step 1.3: Commit Body**
Record: The commit body lists the three binding descriptions added but
provides no bug description or symptom. However, the subject does not
use "fix" and reads as a feature addition. Body does not discuss impact.
**Step 1.4: Hidden Bug Fix Detection**
Record: Based on subject alone, looks like pure feature addition.
However, based on mailing list discussion (see Phase 4), this is a fix
for a binding/DTS mismatch where the DTS files reference compatibles not
documented in the bindings.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: 1 file changed
(`Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml`), +11
lines, -0 lines. Single surgical YAML addition.
**Step 2.2: Code Flow**
Record: Before: Binding file did not describe the
`marvell,armada7020-cpu-module`, `marvell,db-falcon-carrier`, or
`marvell,armada7020-falcon-carrier` compatibles. After: New `oneOf`
entry documents this 6-level compatible stack. No runtime code affected.
**Step 2.3: Bug Mechanism**
Record: This falls in category (h) Hardware workarounds/documentation
additions - DT binding additions for board compatibles. The "bug" is
that the DTS files already in the tree (b3370479a5f7e) reference
compatibles that are undocumented, causing `make CHECK_DTBS=y` to
produce schema validation warnings.
**Step 2.4: Fix Quality**
Record: Obviously correct - YAML schema change only. Zero runtime risk.
Minimal and surgical. Cannot introduce regression as DT schema is not
used at runtime.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
Record: The existing "Armada 7020 SoC" entry that precedes the added
block was present from file creation. New entry inserted after it.
**Step 3.2: Fixes Tag**
Record: No `Fixes:` tag. However, the related DTS commit `b3370479a5f7e`
("arm64: dts: a7k: add COM Express boards", Jan 22 2026) is the commit
that introduced the DTS files referencing the new compatibles, and is
already present in HEAD.
**Step 3.3: File History**
Record: Recent related file history: `4c9bc78fa22d6` (missing 7040/8040
compatibles), `242aa69df6ed8` (8KPlus schema move), `099e1d034f009`
(solidrun cn9132), `5f5eb24090bec` (solidrun cn9130), `c604a4d1833c1`
(earlier Marvell COM Express boards). Part of a typical incremental
binding maintenance flow.
**Step 3.4: Author**
Record: Author Elad Nachman from Marvell has been contributing
Armada/CN913x and ac5 patches. Gregory Clement (mvebu subsystem
maintainer) handled the commit. Rob Herring (top-level DT maintainer)
Acked it.
**Step 3.5: Dependencies**
Record: Standalone binding addition, no code dependencies. However,
contextually linked to DTS commit `b3370479a5f7e` (already in
HEAD/v7.0).
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Lore Discussion**
Record: Found via `b4 dig`: https://lore.kernel.org/all/20260122165923.2
316510-2-enachman@marvell.com/ — Patch 1/3 of series "arm64: dts: a7k:
add COM Express boards". Crucial reviewer feedback found:
- Rob Herring (Mar 6, 2026): *"It seems the .dts files are in 7.0 and
the binding is only in next. The binding needs to go into 7.0 too.
Please pay attention to the warnings."*
- Gregory Clement (Mar 13, 2026): *"Sorry for this. I have now applied
the binding, and it will be included in my next fixes PR."*
This is an **explicit stable nomination from the DT maintainer** for
7.0.y.
**Step 4.2: Reviewers**
Record: Rob Herring (DT maintainer) Acked it, Gregory Clement (mvebu
maintainer) applied and explicitly targeted 7.0 fixes. Proper subsystem
review occurred.
**Step 4.3: Bug Report**
Record: Rob's dt-schema bot flagged "new warnings" on the series.
Warnings are DT validation errors produced by the DTS files without
matching bindings.
**Step 4.4: Series**
Record: Part of a 3-patch series. Patch 2 (DTS) already merged to 7.0.
Patch 3 (MAINTAINERS) has its own destiny. This patch 1 (bindings) is
the reviewer-requested sync.
**Step 4.5: Stable Mailing List**
Record: Not discussed on stable list; this is being handled as a 7.0
fixes path.
## PHASE 5: CODE SEMANTIC ANALYSIS
Not applicable — no code functions involved, only DT YAML schema. DT
binding files have no runtime callers; they are consumed only by `dt-
schema` validation tools (`make dt_binding_check`, `make CHECK_DTBS=y`).
Record: Zero runtime call paths, zero runtime consumers. Binding file
affects only build-time validation.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable**
Record: Verified with `git merge-base --is-ancestor b3370479a5f7e HEAD`
-> IN HEAD. The DTS files (`db-falcon-carrier-a7k.dts`, `db-falcon-
carrier.dtsi`, `armada-7020-comexpress.dtsi`) are present in
stable/linux-7.0.y via mvebu-dt64-6.20-1 merge. The mismatched bindings
cause the validation gap in 7.0.y. Not in older stable trees (6.6.y,
6.1.y etc.), so they aren't affected.
**Step 6.2: Backport Complications**
Record: Binding file in HEAD matches the pre-patch state from mainline.
Patch should apply cleanly to 7.0.y. Verified file context still has the
"Armada 7040 SoC" entry right after the "Armada 7020 SoC" entry -
insertion point unchanged.
**Step 6.3: Related Fixes in Stable**
Record: No related binding fixes already in stable.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem Criticality**
Record: Subsystem = `Documentation/devicetree/bindings/arm/marvell/`, DT
binding documentation. Criticality: PERIPHERAL (affects only DT schema
validators, not any runtime path).
**Step 7.2: Activity Level**
Record: Moderately active file, typical maintenance pace.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Who is Affected**
Record: Developers/testers running `make dt_binding_check` or `make
CHECK_DTBS=y` on the arm64 marvell DTS tree. No end users affected (DT
schema files are not compiled into the kernel or used at runtime).
**Step 8.2: Trigger Conditions**
Record: The "bug" (validation warning) triggers only when someone runs
DT schema validation against the shipped DTS files. Not runtime
reachable.
**Step 8.3: Failure Mode Severity**
Record: LOW - generates `CHECK_DTBS` warnings/failures for validator
users; no crashes, no data corruption, no security impact, no runtime
behavior change.
**Step 8.4: Risk vs Benefit**
Record:
- Benefit: LOW severity, fixes validation inconsistency explicitly
requested by the DT maintainer; keeps 7.0.y internally consistent.
- Risk: Near-zero. 11-line YAML file touching schema metadata only;
cannot affect compile or runtime.
- Ratio: LOW/near-zero = favorable.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
FOR backport:
- DT maintainer (Rob Herring) explicitly stated: "The binding needs to
go into 7.0 too."
- Companion DTS commit `b3370479a5f7e` is already in stable/linux-7.0.y
(verified)
- Fixes DT schema validation warnings against the already-shipped DTS
- Zero runtime risk (YAML metadata only)
- Acked-by DT maintainer, applied to mvebu/fixes (7.0 fixes) by mvebu
maintainer
- Small (11 lines), contained, obviously correct
- Falls under the "Documentation" and "DT updates for existing hardware
(in tree)" exception categories
AGAINST backport:
- Subject reads as feature addition ("add Marvell 7k COMe boards")
- No `Fixes:` tag, no `Cc: stable` tag
- Technically describes new boards not previously documented
- Doesn't fix any runtime behavior
Unresolved: None — the mailing list discussion resolves the intent.
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? YES (YAML schema addition, acked by DT
maintainer)
2. Fixes a real bug affecting users? BORDERLINE - fixes validator bug
for shipped DTS
3. Important issue? LOW severity (validation warnings, not runtime)
4. Small and contained? YES (11 lines, one file)
5. No new features? YES (no runtime features, binding matches DTS
already in tree)
6. Can apply to stable? YES (applies cleanly to 7.0.y)
**Step 9.3: Exception Categories**
Applicable exceptions:
- "DEVICE TREE (DT) UPDATES: DT binding additions for existing hardware,
DT fixes for incorrect hardware descriptions, enabling already-
supported hardware on new boards - Usually safe because they only
affect specific ARM/embedded platforms."
- "DOCUMENTATION and COMMENT FIXES: Fixing incorrect documentation,
updating obsolete comments - Zero risk of runtime regression"
The DTS files for this hardware are already present in 7.0; adding the
matching bindings is a documentation sync.
**Step 9.4: Decision**
For 7.0.y specifically, the DTS files exist in the tree, the DT
maintainer explicitly asked for this to land in 7.0, and the risk is
zero. This matches the exception for DT updates / documentation fixes.
## Verification
- [Phase 1] Parsed tags: `Acked-by: Rob Herring`, `Signed-off-by:
Gregory CLEMENT`, no `Fixes:`/`Cc: stable`.
- [Phase 2] Diff analysis: +11 lines of YAML added to
`armada-7k-8k.yaml`, single file, new `oneOf` entry for the Falcon
carrier + Armada 7020 CPU module compatible stack.
- [Phase 3] `git log --oneline -- <file>`: file churn is typical
incremental binding maintenance.
- [Phase 3] `git log -1 --format="%H %ci %s" edb7efa767da8` -> March 13,
2026; `b3370479a5f7e` -> January 23, 2026 (DTS, earlier).
- [Phase 3] `git merge-base --is-ancestor b3370479a5f7e HEAD` -> **IN
HEAD** (DTS already in 7.0.y).
- [Phase 3] `git merge-base --is-ancestor edb7efa767da8 HEAD` -> **NOT
IN HEAD** (binding not yet in 7.0.y).
- [Phase 3] `git tag --contains b3370479a5f7e` -> `v7.0` confirms DTS is
in the 7.0 release.
- [Phase 4] `b4 dig -c edb7efa767da8` -> found thread at
lore.kernel.org/all/20260122165923.2316510-2-enachman@marvell.com/.
- [Phase 4] `b4 dig -c edb7efa767da8 -w` -> recipients include robh+dt,
krzysztof.kozlowski+dt, conor+dt, andrew@lunn.ch,
gregory.clement@bootlin.com (all relevant DT/maintainer parties).
- [Phase 4] `b4 dig -c edb7efa767da8 -m /tmp/thread.mbox` -> saved full
thread; confirmed Rob Herring's explicit "The binding needs to go into
7.0 too" and Gregory Clement's response "I have now applied the
binding, and it will be included in my next fixes PR."
- [Phase 4] Rob's dt-bot reported DTB warnings on the series
(`arch/arm64/boot/dts/marvell/db-falcon-carrier-a7k.dtb: ...phy-
mode:0: '10gbase-kr' is not one of [...]`), a separate phy-mode issue,
but confirms validation is run.
- [Phase 5] Not applicable (YAML schema file has no runtime callers).
- [Phase 6] Verified DTS files (`db-falcon-carrier-a7k.dts`, `db-falcon-
carrier.dtsi`, `armada-7020-comexpress.dtsi`) exist in HEAD via `git
show b3370479a5f7e:...` - confirmed they use the compatibles added in
this binding commit.
- [Phase 7] File path: `Documentation/devicetree/bindings/arm/marvell/`
- DT binding docs for Marvell Armada platforms.
- [Phase 8] Severity determined by examining what consumes DT binding
YAMLs (dt-schema validators only); verified no runtime code path uses
these YAML files.
The mailing list evidence is unambiguous: the DT maintainer explicitly
flagged that the DTS files landed in v7.0 but the matching bindings did
not, and requested they go into 7.0 to fix the CHECK_DTBS validation
warnings. The mvebu maintainer applied it to the fixes branch
accordingly. The change is 11 lines of YAML with zero runtime risk,
acked by the DT maintainer, matching already-shipped DTS files in the
7.0 tree.
**YES**
.../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index 4bc7454a5d3ac..7e77310da626f 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -21,6 +21,17 @@ properties:
- const: marvell,armada-ap806-dual
- const: marvell,armada-ap806
+ - description:
+ Falcon (DB-98CX85x0) Development board COM Express Carrier plus
+ Armada 7020 SoC COM Express CPU module
+ items:
+ - const: marvell,armada7020-falcon-carrier
+ - const: marvell,db-falcon-carrier
+ - const: marvell,armada7020-cpu-module
+ - const: marvell,armada7020
+ - const: marvell,armada-ap806-dual
+ - const: marvell,armada-ap806
+
- description: Armada 7040 SoC
items:
- enum:
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] mfd: mt6397: Properly fix CID of MT6328, MT6331 and MT6332
From: Sasha Levin @ 2026-04-28 10:40 UTC (permalink / raw)
To: patches, stable
Cc: Akari Tsuyukusa, AngeloGioacchino Del Regno, Lee Jones,
Sasha Levin, matthias.bgg, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Akari Tsuyukusa <akkun11.open@gmail.com>
[ Upstream commit a09506820afa391e0a8ecc4b05c954f21e50b1de ]
CIDs set for MT6328, MT6331 and MT6332 are not appropriate.
Many Android downstream kernels define CID as below,
MT6328:
#define PMIC6328_E1_CID_CODE 0x2810
#define PMIC6328_E2_CID_CODE 0x2820
#define PMIC6328_E3_CID_CODE 0x2830
MT6331/MT6332:
#define PMIC6331_E1_CID_CODE 0x3110
#define PMIC6331_E2_CID_CODE 0x3120
#define PMIC6331_E3_CID_CODE 0x3130
#define PMIC6332_E1_CID_CODE 0x3210
#define PMIC6332_E2_CID_CODE 0x3220
#define PMIC6332_E3_CID_CODE 0x3230
The current configuration incorrectly uses the revision code as the CID.
Therefore, the driver cannot detect the same PMIC of different revisions.
(E1/E2 for MT6328, E1/E3 for MT6331/MT6332)
Based on these, the CID of MT6328, MT6331 and MT6332 should be corrected.
Additionally, the incorrect MT6331/MT6332 CID overlaps with the MT6320's
actual CID:
#define PMIC6320_E1_CID_CODE 0x1020
#define PMIC6320_E2_CID_CODE 0x2020
This causes a conflict in the switch-case statement of mt6397-irq.c,
this prevents adding support for MT6320.
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260302140045.651727-1-akkun11.open@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information I need. Let me provide the complete
analysis.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem prefix: `mfd: mt6397`
- Action verb: "Properly fix" — explicit bug-fix language
- One-line summary: Corrects wrongly configured CID values for MT6328,
MT6331, and MT6332 PMICs
- **Record:** `[mfd/mt6397]` `[fix]` — Properly fix CID values for
MT6328/MT6331/MT6332 PMICs so they get correctly recognized
**Step 1.2: Tags**
- `Signed-off-by:` Akari Tsuyukusa (author)
- `Reviewed-by:` AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>
- `Link:` https://patch.msgid.link/20260302140045.651727-1-
akkun11.open@gmail.com
- `Signed-off-by:` Lee Jones <lee@kernel.org> (MFD maintainer)
- No `Fixes:` tag, no `Cc: stable` — expected, and why the commit is
under review
- **Record:** Reviewed by the subsystem expert who authored the original
MT6331 support (AngeloGioacchino Del Regno) and committed by the
subsystem maintainer (Lee Jones).
**Step 1.3: Body Analysis**
- Bug description: The values previously assigned to `MT6328_CHIP_ID`,
`MT6331_CHIP_ID`, and `MT6332_CHIP_ID` were revision codes (E3 in the
MT6328 case, E2 in the MT6331/MT6332 case), not the actual chip
identifiers. The `cid_shift=0` for these chips extracts the lower byte
(= revision), so only one specific revision matches.
- Symptom: Same PMIC of a different revision is not detected; driver
probe fails.
- Secondary effect: The old (incorrect) MT6331/MT6332 CID value 0x20
collides with the real MT6320 CID, blocking future MT6320 support.
- Explicit reference to downstream Android kernels that document the
real CID layout: E-revision occupies bits 0-7, PMIC model occupies
bits 8-15.
- **Record:** Clear explanation of a correctness bug with concrete
hardware consequences.
**Step 1.4: Hidden Bug Fix Detection**
Not hidden — the title uses "Properly fix". This is a straightforward
correctness fix for a mis-identified register layout.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- `drivers/mfd/mt6397-core.c`: 2 lines changed (cid_shift 0→8 for
mt6328_core and mt6331_mt6332_core)
- `include/linux/mfd/mt6397/core.h`: 3 enum values changed
(MT6328=0x30→0x28, MT6331=0x20→0x31, MT6332=0x20→0x32)
- Total: 5 insertions, 5 deletions, 2 files — extremely small, surgical
- **Record:** 2 files, ~5 effective lines of value changes, no logic
changes.
**Step 2.2: Code Flow Change**
In `mt6397_probe()`:
```346:398:/home/sasha/linux-autosel-7.0/drivers/mfd/mt6397-core.c
static int mt6397_probe(struct platform_device *pdev)
{
...
ret = regmap_read(pmic->regmap, pmic_core->cid_addr, &id);
...
pmic->chip_id = (id >> pmic_core->cid_shift) & 0xff;
...
```
The chip_id is read from the hardware CID register (MT6328_HWCID=0x200,
MT6331_HWCID=0x100), then shifted and masked.
- Before fix (`cid_shift=0`): reads low byte = revision code (e.g.,
0x10, 0x20, 0x30)
- After fix (`cid_shift=8`): reads high byte = actual chip model (0x28,
0x31, 0x32), same across all revisions
The enum values are updated correspondingly so that the old "only
revision X works" behavior is preserved for revision X, and the new
behavior additionally supports all revisions.
- **Record:** The fix changes what portion of the 16-bit HWCID register
is used for chip identification.
**Step 2.3: Bug Mechanism**
Category (g) Logic / correctness fix — specifically, wrong bit-field
extraction from a hardware register.
Concretely, MT6328 HWCID returns e.g. 0x2810 (E1), 0x2820 (E2), 0x2830
(E3):
- Old: chip_id = 0x2810 & 0xff = 0x10 / 0x20 / 0x30 — only E3 matches
MT6328_CHIP_ID=0x30
- New: chip_id = (0x28XX >> 8) & 0xff = 0x28 for all revisions → matches
MT6328_CHIP_ID=0x28
Same analysis for MT6331 (only E2=0x3120 matches old 0x20) and MT6332
(only E2=0x3220 matches old 0x20).
When chip_id doesn't match in `mt6397_irq_init()`'s switch statement:
```207:210:/home/sasha/linux-autosel-7.0/drivers/mfd/mt6397-irq.c
default:
dev_err(chip->dev, "unsupported chip: 0x%x\n",
chip->chip_id);
return -ENODEV;
```
→ probe fails → entire MFD (regulators, RTC, keys) is absent → device
unbootable/unusable.
**Step 2.4: Fix Quality**
- Obviously correct given the documented hardware register layout.
- Pure value change; no new control flow.
- The fix preserves the previous working behavior: hardware that matched
before (MT6328 E3, MT6331/MT6332 E2) still matches after, because the
enum value is updated in lockstep with the shift.
- No API change, no locking change, no memory operations touched.
- **Record:** High-quality fix, zero added regression surface.
## PHASE 3: GIT HISTORY
**Step 3.1: Blame**
- MT6328 chip_data and enum entry introduced in `6e31bb8d3a63b` ("mfd:
mt6397: Add initial support for MT6328") — kernel v6.13.
- MT6331/MT6332 chip_data and enum entries introduced in `d9cd0bc604705`
("mfd: mt6397: Add basic support for MT6331+MT6332 PMIC") — kernel
v6.0.
- **Record:** Buggy code has been present since v6.0 (MT6331/MT6332) and
v6.13 (MT6328).
**Step 3.2: Fixes: Tag**
No Fixes: tag provided. The natural "Fixes:" targets would be the two
commits above. Both are in mainline and in stable trees (since v6.0 /
v6.13).
**Step 3.3: File History** — recent `mt6397-core.c` history shows only
incremental PMIC additions and minor cleanups; no concurrent refactors
that would block a backport.
**Step 3.4: Author's Other Commits** — First-time author; the Reviewed-
by is from AngeloGioacchino Del Regno (Collabora), the original author
of the MT6331/MT6332 support and a prolific MediaTek-platform developer.
**Step 3.5: Dependencies** — Standalone, self-contained. No other
commits needed.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original Patch Discussion**
Retrieved the full thread via b4
(lore.kernel.org/all/20260302140045.651727-1-akkun11.open@gmail.com/):
- v1 posted 2026-02-28 by Akari Tsuyukusa
- AngeloGioacchino Del Regno reviewed v1 on 2026-03-02, asked for GitHub
links to be removed, gave Reviewed-by.
- v2 posted 2026-03-02 with Reviewed-by, no code changes.
- Lee Jones applied v2 as commit
`f59b2bc3e6dbcd75c53f1881c1f08a6d3c2a72e5` on 2026-03-06.
- **Record:** Latest version applied; no objections, no stable-specific
discussion either way, no NAKs.
**Step 4.2: Reviewers** — Correct subsystem parties included: Lee Jones
(MFD maintainer), Matthias Brugger (MediaTek), AngeloGioacchino Del
Regno (MediaTek expert), Yassine Oudjana (original MT6328 author), and
the linux-mediatek/arm/kernel lists.
**Step 4.3–4.5: Bug Report Links** — No external bug report; the
reporter is also the author who likely hit this on their own hardware.
No prior stable-list discussion found.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Key Entities Modified**
- `struct chip_data mt6328_core` (initializer constant)
- `struct chip_data mt6331_mt6332_core` (initializer constant)
- `enum chip_id` members MT6328_CHIP_ID, MT6331_CHIP_ID, MT6332_CHIP_ID
**Step 5.2: Callers/Use sites**
- `mt6328_core` / `mt6331_mt6332_core` referenced as `.data` in the
of_device_id table → consumed once per probe by `mt6397_probe()`.
- `MT6328_CHIP_ID` / `MT6331_CHIP_ID` used in the `switch
(chip->chip_id)` inside `mt6397_irq_init()`
(drivers/mfd/mt6397-irq.c).
- `MT6332_CHIP_ID` is only defined; not referenced in switch (MT6332 is
dispatched through MT6331's IRQ path per the combination comment in
mt6397-core.c line 185).
- No users outside the driver — confirmed via repository-wide search.
- **Record:** Very small impact surface; isolated to mt6397 MFD driver.
**Step 5.3–5.4: Call chain** — Only reachable at device probe
(`mt6397_probe`), triggered by the PMIC node in device tree. User impact
path is: boot → PMIC probe reads HWCID → chip_id mismatch → ENODEV → no
regulators/RTC/keys.
**Step 5.5: Similar patterns** — Other PMICs in the same file
(mt6357/mt6358/mt6359) already use `cid_shift = 8` with their SWCID
addresses. The fix brings the three broken entries into line with the
rest of the driver.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable Trees**
Verified directly against local tracked branches:
- `for-greg/6.6-200` (6.6.y): contains MT6331/MT6332 with `cid_shift =
0` and MT6331/MT6332 CHIP_ID = 0x20. MT6328 not present. →
MT6331/MT6332 part of the fix is needed.
- `for-greg/6.12-200` (6.12.y): same state as 6.6.y. → MT6331/MT6332
part needed.
- `for-greg/6.18-200` (6.18.y): has MT6328=0x30 present plus
MT6331/MT6332=0x20. → Full fix applies.
- `for-greg/6.19-200` and `stable/linux-7.0.y`: have both; full fix
applies.
**Step 6.2: Backport Complications**
- 6.6.y and 6.12.y: need a minor adaptation — drop the MT6328 hunks (2
lines) and the MT6328_CHIP_ID enum line. The rest applies cleanly.
Trivial adjustment.
- 6.18.y+: applies cleanly.
**Step 6.3: Related Fixes in Stable** — None; this is the first and only
fix for this issue.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1–7.2:** `drivers/mfd/` is an important subsystem but this
particular driver is device-specific (MediaTek PMIC companion chips for
specific SoCs). Criticality: IMPORTANT for owners of affected MediaTek
hardware (MT6735, MT6795 Helio X10 phones like Sony Xperia M5). Mature
code with steady activity (new PMIC support added periodically).
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected Users**
Driver-specific: users of MediaTek SoCs paired with MT6328 (MT6735-based
devices), MT6331/MT6332 (MT6795 Helio X10, e.g. Sony Xperia M5 — present
as `mt6795-sony-xperia-m5.dts` and `mt6795-xperia-m5.dts` upstream).
**Step 8.2: Trigger Conditions**
Every boot on an affected hardware revision (any MT6328 E1/E2, any
MT6331/MT6332 E1/E3). The revision shipped in each product is fixed by
manufacturing, so a given user will either always hit or never hit the
bug.
**Step 8.3: Failure Mode**
When triggered: `mt6397_irq_init` returns -ENODEV → `mt6397_probe` fails
→ regulator/RTC/keys sub-devices never register → platform effectively
non-functional (no voltage rails programmed, no RTC, no power button).
Severity: HIGH (device unbootable for affected revisions).
**Step 8.4: Risk-Benefit**
- BENEFIT: HIGH — enables full PMIC support for a population of MediaTek
devices that currently cannot boot properly.
- RISK: VERY LOW — 5-line pure value change; the behavior for
previously-working revisions (MT6328 E3, MT6331/MT6332 E2) is
preserved exactly because both the `cid_shift` and enum value move in
lockstep; no new code paths, no locking/memory changes.
## PHASE 9: FINAL SYNTHESIS
**Evidence FOR:**
- Fixes real, user-visible bug preventing PMIC probe on non-matching
hardware revisions.
- Failure mode is severe (device boot regression).
- Fix is small (5 effective lines), obviously correct, and aligns with
all other PMIC entries in the same driver.
- Reviewed and Acked by subsystem expert (original MT6331 author);
applied by subsystem maintainer.
- Buggy code has been in mainline since v6.0 (MT6331/MT6332) and v6.13
(MT6328), so stable users have been exposed for a long time.
- Preserves backward-compatibility for revisions that previously
happened to work.
**Evidence AGAINST:**
- Minor: requires dropping two MT6328 hunks for pre-6.13 stable trees
(trivial adaptation).
- Not accompanied by `Cc: stable` (expected; that's why it's under
review).
**Stable Rules Check:**
1. Obviously correct: YES (pure value change, documented hardware
register layout).
2. Fixes real bug that affects users: YES (broken probe on specific
revisions).
3. Important issue: YES (device unusable without PMIC).
4. Small and contained: YES (5 effective lines).
5. No new features/APIs: YES.
6. Applies to stable: YES (clean on 6.18+/7.0; trivial hunk drop on
6.6/6.12).
**Exception categories:** Not a device-ID/quirk/DT/doc/build-fix per se,
but is a narrow hardware-identification correctness fix — equivalent
spirit to a quirk/device-ID update.
## Verification
- [Phase 1] Parsed tags: Signed-off-by Akari Tsuyukusa, Reviewed-by
AngeloGioacchino Del Regno, Link to patch.msgid.link, Signed-off-by
Lee Jones (MFD maintainer). No stable tag, no Fixes tag.
- [Phase 2] Diff analysis: 2 files, 5 insertions, 5 deletions — verified
by reading the diff; matches b4-retrieved v2 mbox.
- [Phase 2] Verified code flow: read `drivers/mfd/mt6397-core.c` lines
280–398 and confirmed `pmic->chip_id = (id >> pmic_core->cid_shift) &
0xff;`.
- [Phase 2] Verified failure path: read `drivers/mfd/mt6397-irq.c`
switch 178–210; unmatched chip_id returns -ENODEV.
- [Phase 2] Verified enum collision claim: `MT6331/MT6332_CHIP_ID =
0x20` in `include/linux/mfd/mt6397/core.h`.
- [Phase 3] git log on `drivers/mfd/mt6397-core.c`: `6e31bb8d3a63b`
added MT6328 support, `d9cd0bc604705` added MT6331/MT6332 support.
- [Phase 3] `git tag --contains 6e31bb8d3a63b | sort -V` shows v6.13 as
earliest tag.
- [Phase 3] `git tag --contains d9cd0bc604705 | sort -V` shows v6.0 as
earliest tag.
- [Phase 4] `b4 am` retrieved patch thread (4 messages): v1 submitted
2026-02-28, v2 submitted 2026-03-02 with Reviewed-by added and GitHub
links removed, applied as `f59b2bc3e6dbcd75c53f1881c1f08a6d3c2a72e5`
by Lee Jones 2026-03-06.
- [Phase 4] Full thread read at `/tmp/mt6397_mbox/...mbx`; only review
feedback was to remove GitHub links; no NAK, no stable nomination, no
concerns raised.
- [Phase 5] Searched the whole repo for
`MT6328_CHIP_ID|MT6331_CHIP_ID|MT6332_CHIP_ID` — only appear in the
header and `mt6397-irq.c` switch statement.
- [Phase 5] `drivers/mfd/mt6397-core.c` verified: other PMICs
(mt6357/58/59) already use `cid_shift = 8` pattern.
- [Phase 6] `git show for-greg/6.6-200:include/linux/mfd/mt6397/core.h`
— MT6331/MT6332=0x20 present, MT6328 absent.
- [Phase 6] `git show for-greg/6.12-200:include/linux/mfd/mt6397/core.h`
— same as 6.6.y.
- [Phase 6] `git show for-greg/6.18-200:include/linux/mfd/mt6397/core.h`
— MT6328=0x30 and MT6331/MT6332=0x20 present.
- [Phase 6] `git show for-greg/6.6-200:drivers/mfd/mt6397-core.c` —
`mt6331_mt6332_core` with `cid_shift = 0`. Patch hunk for
MT6331/MT6332 applies identically.
- [Phase 8] Device tree usage verified:
`arch/arm64/boot/dts/mediatek/mt6331.dtsi` and
`arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts` use these
compatibles.
- UNVERIFIED: exact distribution of revisions in shipping devices (E1 vs
E2 vs E3) — claim about which specific revisions fail is taken from
commit message and is consistent with the bit-field math, which I
verified.
This is a correctness fix for a mis-decoded PMIC identification register
that makes the driver unable to probe on specific hardware revisions
shipping in real products (MT6735-based phones, MT6795 Helio X10 phones
including Sony Xperia M5). The change is tiny and preserves behavior for
revisions that happened to work before. It has been reviewed by the
MediaTek PMIC expert and landed by the MFD maintainer. Buggy code has
been in stable since v6.0 (MT6331/MT6332) and v6.13 (MT6328).
Backporting is low risk and high benefit; pre-6.13 trees need only to
drop the MT6328 hunks.
**YES**
drivers/mfd/mt6397-core.c | 4 ++--
include/linux/mfd/mt6397/core.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 3e58d0764c7e0..1bdacda9a933f 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -297,7 +297,7 @@ static const struct chip_data mt6323_core = {
static const struct chip_data mt6328_core = {
.cid_addr = MT6328_HWCID,
- .cid_shift = 0,
+ .cid_shift = 8,
.cells = mt6328_devs,
.cell_size = ARRAY_SIZE(mt6328_devs),
.irq_init = mt6397_irq_init,
@@ -313,7 +313,7 @@ static const struct chip_data mt6357_core = {
static const struct chip_data mt6331_mt6332_core = {
.cid_addr = MT6331_HWCID,
- .cid_shift = 0,
+ .cid_shift = 8,
.cells = mt6331_mt6332_devs,
.cell_size = ARRAY_SIZE(mt6331_mt6332_devs),
.irq_init = mt6397_irq_init,
diff --git a/include/linux/mfd/mt6397/core.h b/include/linux/mfd/mt6397/core.h
index b774c3a4bb62e..340fc72e22aa6 100644
--- a/include/linux/mfd/mt6397/core.h
+++ b/include/linux/mfd/mt6397/core.h
@@ -12,9 +12,9 @@
enum chip_id {
MT6323_CHIP_ID = 0x23,
- MT6328_CHIP_ID = 0x30,
- MT6331_CHIP_ID = 0x20,
- MT6332_CHIP_ID = 0x20,
+ MT6328_CHIP_ID = 0x28,
+ MT6331_CHIP_ID = 0x31,
+ MT6332_CHIP_ID = 0x32,
MT6357_CHIP_ID = 0x57,
MT6358_CHIP_ID = 0x58,
MT6359_CHIP_ID = 0x59,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 1/1] crypto: atmel-sha204a - fix blocking and non-blocking rng logic
From: Thorsten Blum @ 2026-04-28 10:41 UTC (permalink / raw)
To: Lothar Rubusch
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260426212947.24757-2-l.rubusch@gmail.com>
On Sun, Apr 26, 2026 at 09:29:47PM +0000, Lothar Rubusch wrote:
> The blocking and non-blocking paths were failing to provide valid entropy
> due to improper buffer management. Reading the buffer starting from byte 1,
> only fetch the 32 bytes of random data from the return message.
>
> Tested on an Atmel SHA204A device.
>
> Before (here for blocking), tests showed repeatedly reading reduced bytes.
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
>
> After, the result will be similar to the following:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> 00000020
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
> Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Tested on SHA204A hardware using rngtest:
$ sudo head -c 300000 /dev/hwrng | rngtest -c 100
rngtest: FIPS 140-2 successes: 100
rngtest: FIPS 140-2 failures: 0
and verified via hexdump that the byte stream is no longer zero-padded.
Tested-by: Thorsten Blum <thorsten.blum@linux.dev>
Thanks,
Thorsten
^ permalink raw reply
* [PATCH AUTOSEL 7.0-6.12] tty: serial: samsung_tty: avoid dev_dbg deadlock
From: Sasha Levin @ 2026-04-28 10:40 UTC (permalink / raw)
To: patches, stable
Cc: Alyssa Milburn, Greg Kroah-Hartman, Sasha Levin,
krzysztof.kozlowski, jirislaby, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-serial
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Alyssa Milburn <amilburn@zall.org>
[ Upstream commit 43c2b86ff633c34831c8430925ba73d7c20da1ad ]
commit a05025d0ce72 ("tty: serial: samsung_tty: use standard
debugging macros") changed the debug prints to dev_dbg, which can
result in deadlocks:
s3c24xx_serial_set_termios can be called with the port lock, and then
calls dev_dbg, which needs the console mutex. At the same time,
s3c24xx_serial_console_write can be called with the console lock
(e.g., inside console_unlock), and needs the port lock.
To avoid this, move one dev_dbg call and just delete the other.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Link: https://patch.msgid.link/aXny9km6N1v9eoXU@zall.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed. Let me write up the full
analysis:
## Complete 9-Phase Analysis
### PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1 - Subject line parsing:**
Record: Subsystem `tty: serial: samsung_tty:`, action verb `avoid`,
summary: avoid dev_dbg deadlock between port lock and console lock.
**Step 1.2 - Commit message tags:**
Record:
- `Signed-off-by: Alyssa Milburn <amilburn@zall.org>` (author)
- `Link: https://patch.msgid.link/aXny9km6N1v9eoXU@zall.org` (original
submission)
- `Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>` (TTY
subsystem maintainer applied)
- No explicit `Fixes:` tag, but the commit body names `a05025d0ce72` as
introducing the issue
- No `Cc: stable@vger.kernel.org` (expected, as the prompt notes)
- No Reviewed-by/Acked-by/Tested-by tags
- No syzbot/Reported-by
**Step 1.3 - Commit body:**
Record: Bug description: `s3c24xx_serial_set_termios` acquires port lock
then calls `dev_dbg`, which goes through printk and can require the
console mutex. Meanwhile `s3c24xx_serial_console_write` runs with the
console lock held (e.g., from `console_unlock`) and acquires the port
lock. Classic AB-BA deadlock (port_lock ↔ console_lock). Fix: move one
`dev_dbg` before the port lock acquisition and remove the second (post-
write register-dump `dev_dbg`).
**Step 1.4 - Hidden bug fix?** Not hidden - explicit "avoid deadlock".
### PHASE 2: DIFF ANALYSIS
**Step 2.1 - Inventory:**
Record: 1 file (`drivers/tty/serial/samsung_tty.c`), +2/-8 lines total
(6 net deletion). One function modified: `s3c24xx_serial_set_termios()`.
Scope: single-file, surgical.
**Step 2.2 - Code flow change:**
Record:
- Before: `uart_port_lock_irqsave(...)` → `dev_dbg("setting ulcon ...")`
→ reg writes → `dev_dbg("uart: ulcon = ... ")` (reading registers
back)
- After: `dev_dbg("setting ulcon ...")` → `uart_port_lock_irqsave(...)`
→ reg writes → (second dev_dbg removed)
The first `dev_dbg` only prints local variables (`ulcon, quot,
udivslot`) so moving it before the lock is safe. The second `dev_dbg`
re-read registers to report actual written values - removing it loses
diagnostic info but avoids the deadlock (moving it outside the lock
would read values that could race with other writes).
**Step 2.3 - Bug mechanism:**
Record: Synchronization fix (category b): removes an AB-BA deadlock
potential between the UART port spinlock (`port->lock`) and the
printk/console locking chain.
Verified dead-lock mechanism:
- `set_termios` holds `port->lock` (uart_port_lock_irqsave)
- `dev_dbg()` expands (when dynamic debug is enabled) to a printk call
that can enter `console_unlock()` → `console->write()` →
`s3c24xx_serial_console_write()` → which calls
`uart_port_lock_irqsave(cons_uart, &flags)` = same port lock. On the
same CPU that would self-deadlock; across CPUs it forms the AB-BA
pattern with another printk path.
- Confirmed `s3c24xx_serial_console_write` does
`uart_port_lock_irqsave(cons_uart, &flags)` (samsung_tty.c lines
2280-2283 in HEAD).
**Step 2.4 - Fix quality:**
Record: Fix is obvious - debug prints are diagnostic-only; moving one
out and removing the other cannot change functional behavior. Zero risk
of regression from the fix itself. Only downside: loss of one diagnostic
print.
### PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1 - Blame/introduction:**
Record: The problematic `dev_dbg` calls were introduced by `a05025d0ce72
"tty: serial: samsung_tty: use standard debugging macros"` (Greg KH, Dec
2019). `git describe --contains a05025d0ce72` → `v5.6-rc1~139^2~130`,
i.e. first released in v5.6 (March 2020).
**Step 3.2 - Fixes target:**
Record: Named `a05025d0ce72` is present in all current LTS stable trees
(5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y, and 7.0.y). Before
`a05025d0ce72`, the samsung_tty driver used a custom `dbg()` macro that
routed to `printascii()` (low-level ARM debug UART write, no locking) -
that's why the original code wasn't a deadlock. After `a05025d0ce72`,
the conversion to `dev_dbg()` introduced the deadlock potential.
**Step 3.3 - File history:**
Record: Recent changes to `drivers/tty/serial/samsung_tty.c` are a small
trickle (Exynos850 earlycon, 18 port support, cast cleanup, etc.). No
churn in the set_termios area since a05025d0ce72. Standalone patch (not
part of a series) - confirmed via `b4 dig -a` showing only v1.
**Step 3.4 - Author context:**
Record: Alyssa Milburn has submitted other kernel patches (media
subsystem from previous years). Not the samsung TTY maintainer, but the
patch was applied by Greg KH (TTY maintainer) after CC'ing the proper
subsystem maintainers.
**Step 3.5 - Dependencies:**
Record: None. Fix is self-contained and touches only local code within
one function.
### PHASE 4: MAILING LIST RESEARCH
**Step 4.1 - Original thread:**
Record: `b4 dig -c 43c2b86ff633c` found match at
https://patch.msgid.link/aXny9km6N1v9eoXU@zall.org. Fetched via `b4 am`
to `/tmp/b4_samsung/`. No review replies found in the thread (the mbox
from b4 contained only the original patch - `b4 am` reported "Analyzing
0 code-review messages"). Single version - no v2/v3.
**Step 4.2 - Recipients (b4 dig -w):**
Record: Proper CC list: Krzysztof Kozlowski (samsung-soc maintainer),
Alim Akhtar (samsung platform maintainer), Greg Kroah-Hartman (TTY
maintainer), Jiri Slaby (TTY co-maintainer), Faraz Ata (samsung
contributor), linux-serial, linux-samsung-soc, linux-arm-kernel, linux-
kernel. Proper maintainer audience; Greg KH signed off, indicating the
TTY maintainer accepted it.
**Step 4.3 - Bug report:**
Record: No `Reported-by:`, no bug URL. The author appears to have
identified the issue through code review/lockdep analysis rather than
user report. Similar patterns have been found by lockdep in other serial
drivers.
**Step 4.4 - Related patches:**
Record: None (single patch).
**Step 4.5 - Stable list:**
Record: Not investigated further; lore.kernel.org fetching is blocked by
Anubis bot-protection. However, `b4` successfully retrieved the thread
without review feedback, so there was no stable-related discussion.
### PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1 - Key functions:**
Record: `s3c24xx_serial_set_termios` is the only function modified.
**Step 5.2 - Callers of set_termios:**
Record: Called via `uport->ops->set_termios(...)` from serial_core.c at
three sites: (1) `uart_change_line_settings` (normal termios change),
(2) `uart_configure_port` (probe path), (3) `uart_resume_port` (resume).
All are triggered by common operations (open, `tcsetattr`, resume).
Confirmed `set_termios` is called WITHOUT the port_lock held by
serial_core - the driver itself acquires it internally.
**Step 5.3 - The console-write side:**
Record: `s3c24xx_serial_console_write` is registered as
`s3c24xx_serial_console.write`. Called from the printk/console subsystem
when the samsung serial is the configured console. Takes
`cons_uart->lock` via `uart_port_lock_irqsave(cons_uart, &flags)` (lines
2278-2283). This forms the second half of the AB-BA.
**Step 5.4 - Reachability:**
Record: Deadlock trigger requires: (a) dynamic debug enabled for these
specific `dev_dbg` statements in samsung_tty.c, AND (b) samsung_tty
serves as a console, AND (c) a termios change happens (user
`tcsetattr()`, getty open, resume) while another CPU/task is doing a
printk that's flushing via this console. Practical trigger is uncommon
in production (dynamic debug is off by default) but clearly reachable
from unprivileged userspace when enabled.
**Step 5.5 - Similar patterns:**
Record: Confirmed similar fixes in other serial drivers: `436c979360017
"serial: stm32: fix a deadlock in set_termios"` (same AB-BA between
`&port_lock_key` and `console_owner`), `7fd6f640f2dd1 "serial: 8250_dw:
Fix deadlock in LCR workaround"`, `62b2caef400c1 "drivers: tty: serial:
Fix deadlock in sa1100_set_termios()"`. Well-established bug-class with
accepted fixes.
### PHASE 6: STABLE TREE ANALYSIS
**Step 6.1 - Buggy code in stable:**
Record: The buggy structure (port_lock acquired before `dev_dbg`) is
present in all stable trees ≥ 5.6 (where a05025d0ce72 first appeared).
Verified in 7.0.y HEAD (stable/linux-7.0.y) - the current checkout
contains exactly the pre-patch code. Stable trees 5.10, 5.15, 6.1, 6.6,
6.12, 7.0 are affected.
**Step 6.2 - Backport difficulty:**
Record: Very low difficulty. The hunk context is stable identifiers
(`ulcon, quot, udivslot` variables, `wr_regl(port, S3C2410_ULCON,
ulcon)`). Only complication: older stable trees used
`spin_lock_irqsave(&port->lock, flags)` instead of
`uart_port_lock_irqsave(port, &flags)` (the port-lock wrappers were
introduced by 97d7a9aeba1d4 "serial: samsung_tty: Use port lock
wrappers" which went to various stable trees). Still trivial to backport
by substituting the correct lock call; git will likely auto-apply with
minor context fuzz in old trees.
**Step 6.3 - Already in stable?**
Record: No prior fix for this deadlock in stable trees (confirmed by
file history).
### PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1 - Criticality:**
Record: Subsystem = tty/serial driver for Samsung SoCs (Exynos family,
Apple A7-A11, S3C). Criticality: PERIPHERAL (specific-hardware), but
used extensively on Samsung/Exynos-based embedded systems, Chromebooks,
Google Pixel/development boards, and similar ARM platforms. These
devices often use the samsung_tty as their primary console, which is
exactly the configuration where the deadlock matters.
**Step 7.2 - Activity:**
Record: Mature driver, low-churn subsystem. Active maintenance by
Krzysztof Kozlowski and Greg KH. 20 commits over the last ~2 years per
file history.
### PHASE 8: IMPACT AND RISK
**Step 8.1 - Affected users:**
Record: Users of samsung_tty on Exynos, S3C, Apple Silicon (A7-A11 via
this driver), etc. ARM/ARM64 platforms with Samsung or Apple early SoCs.
Limited to systems where dynamic debug is enabled for this file AND the
UART is a console.
**Step 8.2 - Trigger:**
Record: Requires unusual runtime config (dynamic debug on), so not
common in stock distros. However, fully reachable from userspace
(`tcsetattr()`) once dynamic debug is enabled. Developers debugging on
these platforms can hit it.
**Step 8.3 - Failure mode severity:**
Record: Hard hang (deadlock) - system becomes unresponsive. Severity if
triggered: CRITICAL (system hang). Probability: LOW in production,
HIGHER during debugging sessions.
**Step 8.4 - Benefit/risk:**
Record: BENEFIT = correctness fix for a recognized deadlock class (same
pattern fixed in stm32, 8250_dw, sa1100). RISK = essentially zero: no
functional behavior change, only debug-print placement. 2 insertions, 8
deletions, all in one function. Obviously correct on inspection.
Risk/benefit strongly favors backport.
### PHASE 9: SYNTHESIS
**Step 9.1 - Evidence:**
FOR backport:
- Fixes a real AB-BA deadlock between `port_lock` and the console
subsystem locking
- Extremely small, contained change (+2/-8 lines in a single function)
- Zero risk of behavior regression (only debug prints affected)
- Applied by the TTY subsystem maintainer (Greg KH)
- Proper maintainers and lists were CC'd
- Same bug class has been fixed in other serial drivers (stm32, sa1100,
8250_dw) and those fixes reached stable
- Buggy code has existed since v5.6 (2019), in every LTS tree
AGAINST:
- Trigger requires dynamic debug to be enabled for this file; not a
default-config hang
- No reporter, no lockdep report in the commit message (identified by
code inspection)
- Second `dev_dbg` is deleted rather than relocated (minor loss of
diagnostic info)
**Step 9.2 - Stable rules check:**
1. Obviously correct? YES - inspection-verifiable, no behavioral change
beyond debug placement
2. Fixes a real bug? YES - AB-BA deadlock (class well-documented)
3. Important issue? YES - deadlock/hang
4. Small and contained? YES - 10 lines, one function
5. No new features/APIs? YES - only relocates/removes debug prints
6. Applies to stable? YES - trivial with minor wrapper-name substitution
for older trees
**Step 9.3 - Exception category:** Not an exception case; it's a true
bug fix.
**Step 9.4 - Decision:** YES.
## Verification
- [Phase 1] Parsed tags: Link to patch.msgid.link, SOB author Alyssa
Milburn, SOB Greg KH as committer; no Fixes tag but body names
a05025d0ce72 as introducing commit.
- [Phase 2] Diff: 2 insertions, 8 deletions, single function
`s3c24xx_serial_set_termios`.
- [Phase 2] Verified `s3c24xx_serial_console_write` takes
`uart_port_lock_irqsave(cons_uart, &flags)` (samsung_tty.c lines
2278-2283), confirming the port-lock half of the AB-BA.
- [Phase 3] `git show a05025d0ce72` confirmed it replaced `dbg()` (a
`printascii`-based macro) with `dev_dbg()` - verifying the regression
introduction.
- [Phase 3] `git describe --contains a05025d0ce72` →
`v5.6-rc1~139^2~130`, so bug first appeared in v5.6.
- [Phase 3] `git log -- drivers/tty/serial/samsung_tty.c` shows no
existing fix in tree; checked the 20 recent commits.
- [Phase 3] Found related file-history commit `97d7a9aeba1d4 "serial:
samsung_tty: Use port lock wrappers"` that changed `spin_lock_irqsave`
→ `uart_port_lock_irqsave`; relevant for backport to older trees.
- [Phase 4] `b4 dig -c 43c2b86ff633c` matched the patch by patch-id to
lore thread `aXny9km6N1v9eoXU@zall.org`.
- [Phase 4] `b4 dig -c 43c2b86ff633c -a` confirmed single revision (v1
only).
- [Phase 4] `b4 dig -c 43c2b86ff633c -w` confirmed proper recipients
(Krzysztof Kozlowski, Alim Akhtar, Greg KH, Jiri Slaby, linux-serial,
linux-samsung-soc).
- [Phase 4] `b4 am` fetched the thread; only the original patch, no
review replies.
- [Phase 5] Traced `->set_termios` callers in serial_core.c: three sites
(`uart_change_line_settings`, `uart_configure_port`,
`uart_resume_port`), all reachable from common userspace operations;
confirmed serial_core does NOT hold port lock when calling
set_termios.
- [Phase 5] Found similar accepted fixes for the same deadlock class:
`436c979360017` (stm32), `7fd6f640f2dd1` (8250_dw), `62b2caef400c1`
(sa1100).
- [Phase 6] Verified current stable/linux-7.0.y HEAD contains the pre-
patch buggy structure in `s3c24xx_serial_set_termios` (samsung_tty.c
lines 1562-1595).
- [Phase 6] Upstream commit SHA in origin/master:
`43c2b86ff633c34831c8430925ba73d7c20da1ad`.
- [Phase 8] Confirmed trigger conditions require dynamic debug enabled
(`dev_dbg` is no-op otherwise) AND samsung_tty serving as console -
partially gating severity.
- UNVERIFIED: Could not fetch lore.kernel.org directly (Anubis bot-
protection). Had to rely on `b4` tooling, which reported zero review
replies - so there's likely no stable-relevant discussion I missed,
but I cannot 100% guarantee it.
- UNVERIFIED: Did not enumerate every LTS tree's exact file contents;
relied on (a) the described introduction in 2019 and (b) no file-
history fix. Minor lock-wrapper adjustments may be needed for < 6.6.y
backports (older trees use `spin_lock_irqsave(&port->lock, ...)`
pre-97d7a9aeba1d4).
## Summary
This is a small (+2/-8 lines), surgical fix for an AB-BA deadlock
between the UART port lock and the console locking chain, introduced in
v5.6 (2019) when the driver's local `dbg()` macro - which routed to a
lock-free `printascii()` - was converted to `dev_dbg()` that enters the
full printk path. The fix moves one `dev_dbg` out of the critical
section and removes another redundant one. It meets all stable-kernel
criteria: obviously correct, fixes a real deadlock, small/contained, no
new features, and applies with at most trivial context adjustment. The
same bug class has precedent backports in stm32, sa1100, and 8250_dw
serial drivers.
**YES**
drivers/tty/serial/samsung_tty.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index c1fabad6ba1fa..e27806bf2cf3e 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -1562,12 +1562,12 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
ulcon |= S3C2410_LCON_PNONE;
}
- uart_port_lock_irqsave(port, &flags);
-
dev_dbg(port->dev,
"setting ulcon to %08x, brddiv to %d, udivslot %08x\n",
ulcon, quot, udivslot);
+ uart_port_lock_irqsave(port, &flags);
+
wr_regl(port, S3C2410_ULCON, ulcon);
wr_regl(port, S3C2410_UBRDIV, quot);
@@ -1587,12 +1587,6 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
if (ourport->info->has_divslot)
wr_regl(port, S3C2443_DIVSLOT, udivslot);
- dev_dbg(port->dev,
- "uart: ulcon = 0x%08x, ucon = 0x%08x, ufcon = 0x%08x\n",
- rd_regl(port, S3C2410_ULCON),
- rd_regl(port, S3C2410_UCON),
- rd_regl(port, S3C2410_UFCON));
-
/*
* Update the per-port timeout.
*/
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net v6] net: stmmac: Prevent NULL deref when RX memory exhausted
From: Paolo Abeni @ 2026-04-28 10:40 UTC (permalink / raw)
To: Sam Edwards, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski
Cc: Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Maxime Chevallier, Ovidiu Panait, Vladimir Oltean, Baruch Siach,
Serge Semin, Giuseppe Cavallaro, netdev, linux-stm32,
linux-arm-kernel, linux-kernel, stable, Russell King
In-Reply-To: <20260422044503.5349-1-CFSworks@gmail.com>
On 4/22/26 6:45 AM, Sam Edwards wrote:
> The CPU receives frames from the MAC through conventional DMA: the CPU
> allocates buffers for the MAC, then the MAC fills them and returns
> ownership to the CPU. For each hardware RX queue, the CPU and MAC
> coordinate through a shared ring array of DMA descriptors: one
> descriptor per DMA buffer. Each descriptor includes the buffer's
> physical address and a status flag ("OWN") indicating which side owns
> the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set
> the flag and the MAC is only allowed to clear it, and both must move
> through the ring in sequence: thus the ring is used for both
> "submissions" and "completions."
>
> In the stmmac driver, stmmac_rx() bookmarks its position in the ring
> with the `cur_rx` index. The main receive loop in that function checks
> for rx_descs[cur_rx].own=0, gives the corresponding buffer to the
> network stack (NULLing the pointer), and increments `cur_rx` modulo the
> ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
> position with `dirty_rx`, allocates fresh buffers and rearms the
> descriptors (setting OWN=1). If it fails any allocation, it simply stops
> early (leaving OWN=0) and will retry where it left off when next called.
>
> This means descriptors have a three-stage lifecycle (terms my own):
> - `empty` (OWN=1, buffer valid)
> - `full` (OWN=0, buffer valid and populated)
> - `dirty` (OWN=0, buffer NULL)
>
> But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In
> the past (see 'Fixes:'), there was a bug where the loop could cycle
> `cur_rx` all the way back to the first descriptor it dirtied, resulting
> in a NULL dereference when mistaken for `full`. The aforementioned
> commit resolved that *specific* failure by capping the loop's iteration
> limit at `dma_rx_size - 1`, but this is only a partial fix: if the
> previous stmmac_rx_refill() didn't complete, then there are leftover
> `dirty` descriptors that the loop might encounter without needing to
> cycle fully around. The current code therefore panics (see 'Closes:')
> when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to
> catch up to `dirty_rx`.
>
> Fix this by explicitly checking, before advancing `cur_rx`, if the next
> entry is dirty; exit the loop if so. This prevents processing of the
> final, used descriptor until stmmac_rx_refill() succeeds, but
> fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix
> intended: so remove the clamp as well. Since stmmac_rx_zc() is a
> copy-paste-and-tweak of stmmac_rx() and the code structure is identical,
> any fix to stmmac_rx() will also need a corresponding fix for
> stmmac_rx_zc(). Therefore, apply the same check there.
>
> In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the
> MAC sets OWN=0 on the final descriptor, it will be unable to send any
> further DMA-complete IRQs until it's given more `empty` descriptors.
> Currently, the driver simply *hopes* that the next stmmac_rx_refill()
> succeeds, risking an indefinite stall of the receive process if not. But
> this is not a regression, so it can be addressed in a future change.
>
> Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun")
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221010
> Cc: stable@vger.kernel.org
> Suggested-by: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
> ---
>
> This is v6 of [1], which was itself split out of [2]. This patch prevents a
> NULL dereference in the stmmac receive path, and (at Russell's suggestion) in
> the zero-copy path as well.
>
> The approach is different from the previous version and checks the dirty_rx
> index in the loop proper, copied directly from Russell's suggestion [3]. Parts
> of the commit message also use his phrasing. For these reasons he is credited
> with `Suggested-by`.
>
> The commit message now acknowledges the pipeline stall that can occur in case
> of failure of the next stmmac_rx_refill() after the MAC consumes the final
> descriptor. I still intend to fix that bug when I can find the time to finish
> investigating and implement the timer as requested by Jakub, however I'm
> sending this patch now to resolve the outright _panic_ and simplify review.
> The stmmac_rx_zc() path is not affected by this stall.
>
> [1] https://lore.kernel.org/netdev/20260415023947.7627-1-CFSworks@gmail.com/
> [2] https://lore.kernel.org/netdev/20260401041929.12392-1-CFSworks@gmail.com/
> [3] https://lore.kernel.org/netdev/ad-LAB08-_rpmMzK@shell.armlinux.org.uk/
>
> ---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index ca68248dbc78..3591755ea30b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -5549,9 +5549,12 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
> break;
>
> /* Prefetch the next RX descriptor */
> - rx_q->cur_rx = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
> - priv->dma_conf.dma_rx_size);
> - next_entry = rx_q->cur_rx;
> + next_entry = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
> + priv->dma_conf.dma_rx_size);
> + if (unlikely(next_entry == rx_q->dirty_rx))
> + break;
Sashiko notes that breaking the loop of DMA descriptors owned by the CPU
may cause double accounting for the ingress stats by stmmac_rx_status().
AFAICS that is not a regression, as the existing later XDP check already
does the same, so I think that problem should be addressed separately.
/P
^ permalink raw reply
* [PATCH 7/8] KVM: arm64: Propagate stage-2 map failure on guest->host share
From: Fuad Tabba @ 2026-04-28 10:30 UTC (permalink / raw)
To: maz, oliver.upton
Cc: james.morse, suzuki.poulose, yuzenghui, qperret, vdonnefort,
tabba, catalin.marinas, will, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-1-tabba@google.com>
__pkvm_guest_share_host() updates the guest stage-2 PTE for a
guest-OWNED page to PKVM_PAGE_SHARED_OWNED via
kvm_pgtable_stage2_map() and then transitions the host vmemmap and
stage-2 PTE to PKVM_PAGE_SHARED_BORROWED. The map's return value was
wrapped in WARN_ON() and otherwise discarded.
At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands
to a BRK that enters the invalid-host-el2 vector and branches to
hyp_panic(), declared __noreturn.
__pkvm_guest_share_host() calls get_valid_guest_pte() before the
map, which verifies that a valid last-level (PAGE_SIZE) leaf PTE
already exists for the IPA. Because the leaf and all intermediate
tables are in place, the subsequent kvm_pgtable_stage2_map()
replacing it cannot fail via -ENOMEM: no block to split, no new
tables to install. The failure path is not currently reachable.
Nevertheless, WARN_ON() on any fallible call is the wrong pattern at
EL2: if the get_valid_guest_pte() precondition were ever relaxed, or
the walker gained a new failure mode, the WARN_ON would convert a
recoverable error into a fatal hyp panic. Capture the return value
and propagate it. The unmap() is kept as a defensive guard for the
currently unreachable failure path; no host-side unwinding is needed
since the host vmemmap and stage-2 update is the next step and is
correctly skipped on error.
Fixes: 03313efed5e2 ("KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index b8c57a95e9bf..6fb546af699f 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -979,10 +979,23 @@ int __pkvm_guest_share_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
if (__host_check_page_state_range(phys, PAGE_SIZE, PKVM_NOPAGE))
goto unlock;
- ret = 0;
- WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
- pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_SHARED_OWNED),
- &vcpu->vcpu.arch.pkvm_memcache, 0));
+ ret = kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
+ pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_SHARED_OWNED),
+ &vcpu->vcpu.arch.pkvm_memcache, 0);
+ if (ret) {
+ /*
+ * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the
+ * memcache), leaving partial leaf entries in the guest
+ * stage-2 transitioned to PKVM_PAGE_SHARED_OWNED. Tear
+ * them down so the host does not see a partially-shared
+ * mapping it has not yet acknowledged via the host
+ * stage-2 update below. No host bookkeeping needs
+ * unwinding here: the only mutation prior to the failed
+ * map is the (now-discarded) guest stage-2 update itself.
+ */
+ kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE);
+ goto unlock;
+ }
WARN_ON(__host_set_page_state_range(phys, PAGE_SIZE, PKVM_PAGE_SHARED_BORROWED));
unlock:
guest_unlock_component(vm);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 8/8] KVM: arm64: Propagate stage-2 map failure on guest->host unshare
From: Fuad Tabba @ 2026-04-28 10:30 UTC (permalink / raw)
To: maz, oliver.upton
Cc: james.morse, suzuki.poulose, yuzenghui, qperret, vdonnefort,
tabba, catalin.marinas, will, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-1-tabba@google.com>
__pkvm_guest_unshare_host() re-acquires exclusive guest ownership of
a page by (i) annotating the host stage-2 PTE via
host_stage2_set_owner_metadata_locked(), (ii) mapping the page in
the guest stage-2 as PKVM_PAGE_OWNED via kvm_pgtable_stage2_map(),
and (iii) restoring host ownership via
host_stage2_set_owner_locked(). The map's return value was wrapped
in WARN_ON() and otherwise discarded.
At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands
to a BRK that enters the invalid-host-el2 vector and branches to
hyp_panic(), declared __noreturn.
__pkvm_guest_unshare_host() calls get_valid_guest_pte() before the
map, which verifies that a valid last-level (PAGE_SIZE) leaf PTE
already exists for the IPA. Because the leaf and all intermediate
tables are in place, the subsequent kvm_pgtable_stage2_map()
replacing it cannot fail via -ENOMEM: no block to split, no new
tables to install. The failure path is not currently reachable.
Nevertheless, WARN_ON() on any fallible call is the wrong pattern at
EL2. Capture the return value and propagate it. The unmap() and
host-side rollback are kept as defensive guards for the currently
unreachable failure path. The rollback's
WARN_ON(__host_set_page_state_range()) asserts an impossible state:
the host leaf PTE was just written by
host_stage2_set_owner_metadata_locked(), so the reverse idmap
rewrite cannot require new page-table allocation from host_s2_pool.
This is the correct use of WARN_ON at EL2 — an impossible-state
assertion, not a reachable error being ignored.
Fixes: 246c976c370d ("KVM: arm64: Implement the MEM_UNSHARE hypercall for protected VMs")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 37 ++++++++++++++++++---------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 6fb546af699f..12f3ea7a2d75 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -984,14 +984,10 @@ int __pkvm_guest_share_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
&vcpu->vcpu.arch.pkvm_memcache, 0);
if (ret) {
/*
- * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the
- * memcache), leaving partial leaf entries in the guest
- * stage-2 transitioned to PKVM_PAGE_SHARED_OWNED. Tear
- * them down so the host does not see a partially-shared
- * mapping it has not yet acknowledged via the host
- * stage-2 update below. No host bookkeeping needs
- * unwinding here: the only mutation prior to the failed
- * map is the (now-discarded) guest stage-2 update itself.
+ * Defensive: get_valid_guest_pte() guarantees a last-level
+ * leaf PTE already exists, so stage-2 map() cannot currently
+ * fail here. The unmap() restores the IPA to a clean state as
+ * a guard should the precondition ever change.
*/
kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE);
goto unlock;
@@ -1024,13 +1020,30 @@ int __pkvm_guest_unshare_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
if (__host_check_page_state_range(phys, PAGE_SIZE, PKVM_PAGE_SHARED_BORROWED))
goto unlock;
- ret = 0;
meta = host_stage2_encode_gfn_meta(vm, gfn);
WARN_ON(host_stage2_set_owner_metadata_locked(phys, PAGE_SIZE,
PKVM_ID_GUEST, meta));
- WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
- pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED),
- &vcpu->vcpu.arch.pkvm_memcache, 0));
+ ret = kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
+ pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED),
+ &vcpu->vcpu.arch.pkvm_memcache, 0);
+ if (ret) {
+ /*
+ * Defensive: get_valid_guest_pte() guarantees a last-level
+ * leaf PTE already exists, so stage-2 map() cannot currently
+ * fail here. The unmap() and host-side rollback below are
+ * kept as guards should the precondition ever change.
+ */
+ kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE);
+
+ /*
+ * Roll back the host stage-2 mutation above: the host leaf
+ * PTE was just written by host_stage2_set_owner_metadata_locked(),
+ * so __host_set_page_state_range() rewrites it in-place
+ * without needing fresh page-table pages from host_s2_pool.
+ */
+ WARN_ON(__host_set_page_state_range(phys, PAGE_SIZE,
+ PKVM_PAGE_SHARED_BORROWED));
+ }
unlock:
guest_unlock_component(vm);
host_unlock_component();
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 6/8] KVM: arm64: Propagate stage-2 map failure on host->guest donation
From: Fuad Tabba @ 2026-04-28 10:30 UTC (permalink / raw)
To: maz, oliver.upton
Cc: james.morse, suzuki.poulose, yuzenghui, qperret, vdonnefort,
tabba, catalin.marinas, will, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-1-tabba@google.com>
__pkvm_host_donate_guest() flips the host stage-2 PTE for the donated
page to a non-valid annotation (KVM_HOST_INVALID_PTE_TYPE_DONATION,
owner = PKVM_ID_GUEST) via host_stage2_set_owner_metadata_locked()
and then calls kvm_pgtable_stage2_map() to install the matching guest
stage-2 mapping. The map's return value was wrapped in WARN_ON() and
otherwise discarded.
At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands
to a BRK that enters the invalid-host-el2 vector and branches to
hyp_panic(), declared __noreturn. WARN_ON of a reachable failure at
EL2 is a panic primitive, not a debug aid.
kvm_pgtable_stage2_map() can fail in reachable ways even at PAGE_SIZE
granularity: __pkvm_host_donate_guest() verifies PKVM_NOPAGE for the
guest IPA before the map, meaning no valid stage-2 entry exists. The
walker must allocate new page-table pages from the vcpu memcache to
install the mapping, returning -ENOMEM if exhausted. The host
controls the vcpu memcache via the topup interface, so an
under-provisioned donation request converts a recoverable error into
a fatal hyp panic.
Capture the stage-2 map return value and propagate it. The walker
may have installed partial leaf entries for the IPA before failing,
so unmap the range to clear them; otherwise the guest would retain
stage-2 access to a page the host is about to reclaim as
PKVM_PAGE_OWNED. Then roll back the host stage-2 mutation: the only
forward mutation is host_stage2_set_owner_metadata_locked() flipping
the host vmemmap from PKVM_PAGE_OWNED to PKVM_NOPAGE and the host
stage-2 PTE from idmap to invalid+annotation.
host_stage2_set_owner_locked(_, _, PKVM_ID_HOST) restores both.
The rollback calls host_stage2_set_owner_locked() under WARN_ON.
This is the correct use: host_stage2_set_owner_metadata_locked()
just wrote the host leaf PTE as an invalid+annotation entry, so the
reverse idmap rewrite cannot require new page-table allocation — it
rewrites the leaf in-place. The WARN_ON asserts an impossible state
under correct EL2 execution, semantically distinct from the misuse
being fixed.
Fixes: 1e579adca177 ("KVM: arm64: Introduce __pkvm_host_donate_guest()")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 7044913a0758..b8c57a95e9bf 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -1391,9 +1391,30 @@ int __pkvm_host_donate_guest(u64 pfn, u64 gfn, struct pkvm_hyp_vcpu *vcpu)
meta = host_stage2_encode_gfn_meta(vm, gfn);
WARN_ON(host_stage2_set_owner_metadata_locked(phys, PAGE_SIZE,
PKVM_ID_GUEST, meta));
- WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
- pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED),
- &vcpu->vcpu.arch.pkvm_memcache, 0));
+ ret = kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
+ pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED),
+ &vcpu->vcpu.arch.pkvm_memcache, 0);
+ if (ret) {
+ /*
+ * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the
+ * memcache), leaving partial leaf entries installed in the
+ * guest stage-2. Tear them down before rolling back the host
+ * stage-2; otherwise the guest would retain access to a page
+ * the host is about to reclaim as PKVM_PAGE_OWNED.
+ */
+ kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE);
+
+ /*
+ * Roll back the donation annotation applied above by
+ * host_stage2_set_owner_metadata_locked() (host vmemmap
+ * PKVM_NOPAGE -> PKVM_PAGE_OWNED, host stage-2 PTE
+ * invalid+annotation -> idmap). The leaf PTE was just
+ * installed by the forward call, so reinstating the idmap
+ * rewrites it without needing fresh page-table pages from
+ * host_s2_pool.
+ */
+ WARN_ON(host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HOST));
+ }
unlock:
guest_unlock_component(vm);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 2/8] KVM: arm64: Synchronise HCR_EL2 writes on the guest exit path
From: Fuad Tabba @ 2026-04-28 10:30 UTC (permalink / raw)
To: maz, oliver.upton
Cc: james.morse, suzuki.poulose, yuzenghui, qperret, vdonnefort,
tabba, catalin.marinas, will, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-1-tabba@google.com>
MSR HCR_EL2 is not self-synchronising. Per ARM DDI 0487 M.b K1.2.4
(p.K1-16823) and B2.6.1 (p.B2-297), a Context Synchronisation Event
is required between an HCR_EL2 write and any subsequent direct
register access at the same EL that depends on the new value being
in effect.
On the entry path, the HCR_EL2 write in __activate_traps is followed
by further EL2 sysreg work (MDCR_EL2, CPTR_EL2, VBAR_EL2, and on the
speculative-AT errata path SCTLR_EL1/TCR_EL1) before ERET into the
guest. None of those intervening accesses depend on the new HCR_EL2
value, and ERET is a CSE per ARM DDI 0487 M.b D1.4.4.1 rule RBWCFK
(p. D1-7209) conditional on SCTLR_EL2.EOS=1, which is set
unconditionally by INIT_SCTLR_EL2_MMU_ON (see the prerequisite patch
in this series). The requirement is therefore satisfied implicitly
on the activate path.
The deactivate path is different: after write_sysreg_hcr() in
__deactivate_traps() further EL2 sysreg work runs before any natural
CSE - on nVHE, __deactivate_cptr_traps and the VBAR_EL2 write; on
VHE, the timer context save which reads CNTP_CVAL_EL0 under the new
TGE/E2H, and the EL1 sysreg restore. Add an explicit isb() at each
of the two deactivate sites.
The practical impact today is bounded: HCR_EL2.E2H does not toggle
in either path, and the trap bits being changed primarily affect
EL1&0 behaviour. But the architectural rule should be honoured.
Note that write_sysreg_hcr() itself already issues isb() on the
Ampere errata path (sysreg.h), confirming the architectural
expectation; the fast path optimises that away.
The fix is at the call sites rather than inside write_sysreg_hcr()
because the macro has many users (e.g. the activate path, at.c,
hardirq.h, ptrauth alternatives) where the immediately-following
code either reaches ERET or has another CSE; making the macro emit
an unconditional ISB would impose unnecessary cost on those
well-formed users.
Fixes: 9404673293b0 ("KVM: arm64: timers: Correctly handle TGE flip with CNTPOFF_EL2")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/switch.c | 11 +++++++++++
arch/arm64/kvm/hyp/vhe/switch.c | 11 +++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 8d1df3d33595..9d7ead5a5503 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -105,6 +105,17 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
__deactivate_traps_common(vcpu);
write_sysreg_hcr(this_cpu_ptr(&kvm_init_params)->hcr_el2);
+ /*
+ * MSR HCR_EL2 is not self-synchronising. Per ARM ARM K1.2.4 p.K1-16823
+ * and B2.6.1 p.B2-297, a Context Synchronisation Event is required
+ * between an HCR_EL2 write and any subsequent direct register access at
+ * the same EL that depends on the new value being in effect.
+ * The activate_traps path falls through to ERET (a CSE), but the
+ * deactivate path still executes further EL2 sysreg work (CPTR/VBAR
+ * writes below) before any natural CSE, so make the synchronisation
+ * explicit.
+ */
+ isb();
__deactivate_cptr_traps(vcpu);
write_sysreg(__kvm_hyp_host_vector, vbar_el2);
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 9db3f11a4754..140d3bcb5651 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -149,6 +149,17 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
___deactivate_traps(vcpu);
write_sysreg_hcr(HCR_HOST_VHE_FLAGS);
+ /*
+ * MSR HCR_EL2 is not self-synchronising. Per ARM ARM K1.2.4 p.K1-16823
+ * and B2.6.1 p.B2-297, a Context Synchronisation Event is required
+ * between an HCR_EL2 write and any subsequent direct register access at
+ * the same EL that depends on the new value being in effect.
+ * The activate_traps path falls through to ERET (a CSE), but the
+ * deactivate path still executes further EL2 sysreg work (CPTR/VBAR
+ * writes below) before any natural CSE, so make the synchronisation
+ * explicit.
+ */
+ isb();
if (has_cntpoff()) {
struct timer_map map;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 4/8] KVM: arm64: Fix __deactivate_fgt macro parameter typo
From: Fuad Tabba @ 2026-04-28 10:30 UTC (permalink / raw)
To: maz, oliver.upton
Cc: james.morse, suzuki.poulose, yuzenghui, qperret, vdonnefort,
tabba, catalin.marinas, will, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-1-tabba@google.com>
__deactivate_fgt() declares its first parameter as "htcxt" but the body
references "hctxt". The parameter is unused; the macro silently captures
"hctxt" from the enclosing scope. Both existing callers
(__deactivate_traps_hfgxtr() and __deactivate_traps_ich_hfgxtr()) happen
to define a local "struct kvm_cpu_context *hctxt", so the macro works
by coincidence.
A future caller without an "hctxt" local in scope, or naming it
differently, would compile but bind to the wrong context. Align the
parameter name with the sibling __activate_fgt() macro.
The "vcpu" parameter remains unused in the body, kept for API symmetry
with __activate_fgt() (which uses it).
Fixes: f5a5a406b4b8 ("KVM: arm64: Propagate and handle Fine-Grained UNDEF bits")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 98b2976837b1..bf0eb5e43427 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -245,7 +245,7 @@ static inline void __activate_traps_ich_hfgxtr(struct kvm_vcpu *vcpu)
__activate_fgt(hctxt, vcpu, ICH_HFGITR_EL2);
}
-#define __deactivate_fgt(htcxt, vcpu, reg) \
+#define __deactivate_fgt(hctxt, vcpu, reg) \
do { \
write_sysreg_s(ctxt_sys_reg(hctxt, reg), \
SYS_ ## reg); \
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 5/8] KVM: arm64: Propagate stage-2 map failure on host->guest share
From: Fuad Tabba @ 2026-04-28 10:30 UTC (permalink / raw)
To: maz, oliver.upton
Cc: james.morse, suzuki.poulose, yuzenghui, qperret, vdonnefort,
tabba, catalin.marinas, will, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-1-tabba@google.com>
__pkvm_host_share_guest() mutates the host vmemmap for every page in
the range (sets PKVM_PAGE_SHARED_OWNED and increments
host_share_guest_count) and then calls kvm_pgtable_stage2_map() to
install the guest stage-2 mapping. The stage-2 map's return value was
wrapped in WARN_ON() and otherwise discarded.
At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands
to a BRK that enters the invalid-host-el2 vector and branches to
hyp_panic(), declared __noreturn. WARN_ON of a reachable failure at
EL2 is a panic primitive, not a debug aid.
kvm_pgtable_stage2_map() can fail in reachable ways: the stage-2
walker requests fresh pages from the caller's memcache and returns
-ENOMEM when the memcache is exhausted mid-walk. The host controls
the vcpu memcache via the topup interface, so an under-provisioned
share request converts a recoverable error into a fatal hyp panic.
Capture the stage-2 map return value and propagate it. The walker
may have installed leaf entries for some pages in the IPA range
before failing, so unmap the range to clear any partial mappings;
otherwise the guest would retain stage-2 access to pages the host is
about to reclaim. Then roll back the host vmemmap mutations from the
forward pass: the forward pass increments the count by 1 on every
page, and the only forward state transition is OWNED -> SHARED_OWNED
(the count 0 -> 1 transition). The reverse pass decrements the count
and, if it drops back to zero, restores PKVM_PAGE_OWNED. Pages
already SHARED_OWNED with other sharers (count > 1 after the forward
pass) only need the count decremented.
Fixes: d0bd3e6570ae ("KVM: arm64: Introduce __pkvm_host_share_guest()")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 30 ++++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 28a471d1927c..7044913a0758 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -1458,9 +1458,33 @@ int __pkvm_host_share_guest(u64 pfn, u64 gfn, u64 nr_pages, struct pkvm_hyp_vcpu
page->host_share_guest_count++;
}
- WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, size, phys,
- pkvm_mkstate(prot, PKVM_PAGE_SHARED_BORROWED),
- &vcpu->vcpu.arch.pkvm_memcache, 0));
+ ret = kvm_pgtable_stage2_map(&vm->pgt, ipa, size, phys,
+ pkvm_mkstate(prot, PKVM_PAGE_SHARED_BORROWED),
+ &vcpu->vcpu.arch.pkvm_memcache, 0);
+ if (ret) {
+ /*
+ * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the
+ * memcache), leaving partial leaf entries installed in the
+ * guest stage-2. Tear them down before rolling back host
+ * bookkeeping; otherwise the guest would retain access to
+ * pages the host is about to reclaim as PKVM_PAGE_OWNED.
+ */
+ kvm_pgtable_stage2_unmap(&vm->pgt, ipa, size);
+
+ /*
+ * Roll back the host vmemmap mutations applied above. A page
+ * whose host_share_guest_count is now 1 was PKVM_PAGE_OWNED
+ * before this call (count 0->1, state OWNED->SHARED_OWNED);
+ * undo both. A page with count > 1 was already
+ * PKVM_PAGE_SHARED_OWNED with other sharers; only the count
+ * needs to be decremented.
+ */
+ for_each_hyp_page(page, phys, size) {
+ page->host_share_guest_count--;
+ if (!page->host_share_guest_count)
+ set_host_state(page, PKVM_PAGE_OWNED);
+ }
+ }
unlock:
guest_unlock_component(vm);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 3/8] KVM: arm64: Guard against NULL vcpu on VHE hyp panic path
From: Fuad Tabba @ 2026-04-28 10:30 UTC (permalink / raw)
To: maz, oliver.upton
Cc: james.morse, suzuki.poulose, yuzenghui, qperret, vdonnefort,
tabba, catalin.marinas, will, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-1-tabba@google.com>
On VHE, __hyp_call_panic() unconditionally calls __deactivate_traps(vcpu)
on the vcpu pointer read from host_ctxt->__hyp_running_vcpu. That pointer
is cleared after every guest exit (and is never set when no guest is
running), so an unexpected EL2 exception landing in _guest_exit_panic,
e.g. via the el2t*_invalid / el2h_irq_invalid vectors - reaches this
function with vcpu == NULL. __deactivate_traps() then dereferences vcpu
via ___deactivate_traps() -> vserror_state_is_nested() -> vcpu_has_nv()
-> vcpu->arch.features, faulting inside the panic handler and obscuring
the original failure.
The nVHE counterpart (hyp_panic() in arch/arm64/kvm/hyp/nvhe/switch.c)
already guards its vcpu-using cleanup with "if (vcpu)"; mirror that
here. sysreg_restore_host_state_vhe() and __hyp_do_panic() do not depend
on vcpu and continue to run unconditionally, preserving panic forensics.
The trailing panic("...VCPU:%p", vcpu) prints "(null)" safely via
printk's %p handling.
Fixes: 6a0259ed29bb ("KVM: arm64: Remove hyp_panic arguments")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/vhe/switch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 140d3bcb5651..8912863cc238 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -674,7 +674,8 @@ static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par)
host_ctxt = host_data_ptr(host_ctxt);
vcpu = host_ctxt->__hyp_running_vcpu;
- __deactivate_traps(vcpu);
+ if (vcpu)
+ __deactivate_traps(vcpu);
sysreg_restore_host_state_vhe(host_ctxt);
panic("HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%016llx PAR:%016llx\nVCPU:%p\n",
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox