[PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10

[PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10

[Sasha Levin]

From: Zhang Heng <zhangheng@kylinos.cn>

[ Upstream commit 7bae956cac0433c4d41aac9f1d04e42694e0b706 ]

This machine is equipped with ALC287 and requires the quirk
ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN to fix the issue
where the bass speakers are not configured and the speaker
volume cannot be controlled.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221210
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260313080624.1395362-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 the full analysis.

---

## Phase 1: Commit Message Forensics

**Step 1.1: Parse the subject line**
Record: [ALSA: hda/realtek] [add] Add a hardware quirk entry so Lenovo
Yoga 7 2-in-1 16AKP10 uses the existing ALC287 bass-speaker fixup.

**Step 1.2: Parse all commit message tags**
Record:
- `Link: https://bugzilla.kernel.org/show_bug.cgi?id=221210` — a filed
  kernel bug report
- `Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>` — the author
- `Link: https://patch.msgid.link/20260313080624.1395362-1-
  zhangheng@kylinos.cn` — patch submission
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>` — ALSA subsystem
  maintainer

Not present: `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`,
`Acked-by:`, `Cc: stable@vger.kernel.org`. Absence of these is expected
for commits under manual review.

**Step 1.3: Analyze the commit body text**
Record: The machine has an ALC287 codec. Without the quirk, bass
speakers are not configured and speaker volume cannot be controlled. A
kernel bugzilla entry (#221210) documents the user-facing issue.

**Step 1.4: Detect hidden bug fixes**
Record: Not a hidden fix — this is an explicit hardware quirk addition
for a known audio routing problem.

---

## Phase 2: Diff Analysis — Line by Line

**Step 2.1: Inventory the changes**
Record: One file changed: `sound/hda/codecs/realtek/alc269.c`. +1 line,
-0 lines. Modified: `alc269_fixup_tbl[]` static table. Scope: single-
file, table-only, surgical.

**Step 2.2: Understand the code flow change**
Record: Before: no entry in `alc269_fixup_tbl[]` for codec SSID
`0x17aa:0x391d`. The ALC287 codec on this laptop gets no fixup applied
to bass speakers. After: `HDA_CODEC_QUIRK(0x17aa, 0x391d, "Lenovo Yoga 7
2-in-1 16AKP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN)` maps this
codec SSID to an existing well-tested fixup. This is an
initialization/probe path change.

**Step 2.3: Identify the bug mechanism**
Record: Category (h) — hardware workaround / audio codec quirk. The
fixup function `alc287_fixup_yoga9_14iap7_bass_spk_pin()` does:
1. Overrides Pin Complex 0x17 configuration (reported wrongly as
   unconnected)
2. Overrides connection list for NID 0x17 to DACs 0x02/0x03 (avoids DACs
   0x06/0x08 which have no volume control)
3. Sets preferred DAC pairing: speakers (0x14, 0x17) → DAC 0x02,
   headphones (0x21) → DAC 0x03

**Step 2.4: Assess the fix quality**
Record: Minimal and obviously correct — one exact-match table entry
reusing a fixup already used by 7+ other Lenovo machines.
`HDA_CODEC_QUIRK` matches on codec SSID (narrower than PCI SSID), so no
other hardware can be affected. Regression risk: effectively zero.

---

## Phase 3: Git History Investigation

**Step 3.1: Blame the changed lines**
Record: `git blame` shows the adjacent sibling entry for `0x391c`
(14AKP10) was introduced by commit `1386d16761c0b5` (J-Donald Tournier,
2025-10-18). The new `0x391d` entry is the 16-inch variant of the same
family. There was no previous `0x391d` line — this is a coverage gap,
not a changed line.

**Step 3.2: Follow the Fixes: tag**
Record: N/A — no `Fixes:` tag present (expected for manually reviewed
candidates).

**Step 3.3: Check file history for related changes**
Record: Recent `alc269.c` history is dominated by quirk additions for
various laptops. Related commits:
- `1386d16761c0b5`: sibling 14AKP10 quirk (same fixup, same
  `HDA_CODEC_QUIRK` pattern)
- `3790a3d6dbbc4`: original `ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN`
  introduction (first in v6.0)
- `504f052aa3435`: introduced `HDA_CODEC_QUIRK` / codec-SSID matching
  for Lenovo (first in v6.13)

This commit is standalone — no patch series, no multi-file dependency.

**Step 3.4: Check the author's other commits**
Record: Zhang Heng is a recurring contributor in
`sound/hda/codecs/realtek/`, with 6+ prior quirk patches found. Not the
subsystem maintainer but an established contributor. Takashi Iwai (ALSA
maintainer) signed off.

**Step 3.5: Check for dependent/prerequisite commits**
Record: This patch depends on two prerequisites:
1. `ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN` — present since v6.0
2. `HDA_CODEC_QUIRK()` macro — present since v6.13 (commit
   `504f052aa3435`)

Both are verified present on HEAD. The patch is standalone for any tree
that has these two prerequisites.

---

## Phase 4: Mailing List and External Research

**Step 4.1–4.4**
Record: Bugzilla #221210 and lore.kernel.org links were inaccessible due
to Anubis bot protection. However, the existence of a kernel bugzilla
report referenced in a maintainer-signed commit provides sufficient
evidence of a documented, real-world user issue. No mailing list review
details could be verified. No stable-specific discussion could be
checked.

---

## Phase 5: Code Semantic Analysis

**Step 5.1: Identify key functions**
Record: The diff modifies `alc269_fixup_tbl[]`. The semantically
affected functions are:
- `snd_hda_pick_fixup()` (reads the table during probe)
- `alc287_fixup_yoga9_14iap7_bass_spk_pin()` (the fixup applied)

**Step 5.2: Trace callers**
Record: `alc269_fixup_tbl` is consumed by `snd_hda_pick_fixup()`, called
from `alc269_probe()` — the standard ALC269-family codec initialization
path. This runs on every system that has this codec.

**Step 5.3: Trace callees**
Record: `alc287_fixup_yoga9_14iap7_bass_spk_pin()` calls:
- `hda_fixup_ideapad_acpi()` — mute LED support
- `snd_hda_apply_pincfgs()` — override pin 0x17 configuration
- `snd_hda_override_conn_list()` — set DAC connections for NID 0x17
- Sets `spec->gen.preferred_dacs` — DAC pairing preferences

**Step 5.4: Follow the call chain**
Record: ALC287 codec → `alc269_probe()` → `snd_hda_pick_fixup()` → table
match on codec SSID → `snd_hda_apply_fixup(HDA_FIXUP_ACT_PRE_PROBE)` →
`alc287_fixup_yoga9_14iap7_bass_spk_pin()`. This path is automatically
exercised on boot on affected hardware. Fully reachable without special
configuration.

**Step 5.5: Search for similar patterns**
Record: The same fixup `ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN` is
already used for 7+ Lenovo models: 0x3801, 0x3869, 0x3882, 0x3891,
0x390d, 0x391c. This is a well-exercised, established pattern.

---

## Phase 6: Cross-Referencing and Stable Tree Analysis

**Step 6.1: Does the buggy code exist in stable trees?**
Record:
- The bass-speaker fixup `ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN` has
  existed since **v6.0**.
- The `HDA_CODEC_QUIRK()` macro (codec-SSID matching) was introduced in
  **v6.13** (`504f052aa3435`).
- The sibling `0x391c` entry first appeared in **v6.18**
  (`1386d16761c0b5`).
- This commit (`7bae956cac043`) first appears in **v7.0-rc6**.

Branch applicability:
- **v6.18.y, v6.19.y**: Trivial one-line addition next to the existing
  `0x391c` sibling. Clean apply expected.
- **v6.13–v6.17**: `HDA_CODEC_QUIRK` exists, fixup exists. Feasible but
  `0x391c` context line is absent.
- **v6.12 and older (v6.6, v6.1, v5.15)**: Lack `HDA_CODEC_QUIRK()`
  macro entirely. Not a standalone backport — would need adaptation
  (e.g., using `SND_PCI_QUIRK` instead, which matches PCI SSID not codec
  SSID).

**Step 6.2: Check for backport complications**
Record: Clean apply on v6.18.y and v6.19.y. Minor context adjustments
for v6.13–v6.17. Not directly applicable for older trees.

**Step 6.3: Check if related fixes are already in stable**
Record: No evidence of an existing `0x391d` entry in any branch. The
sibling `0x391c` is in v6.18+.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1: Identify the subsystem and its criticality**
Record: `sound/hda/codecs/realtek` — ALSA HDA Realtek codec driver.
Criticality: IMPORTANT. While it's a specific driver, Realtek HDA is
among the most widely used audio codecs in laptops. Quirks for this
driver are routine stable material.

**Step 7.2: Assess subsystem activity**
Record: `alc269.c` sees very frequent updates, overwhelmingly quirk
additions for various laptop models. This is completely normal for the
subsystem.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1: Determine who is affected**
Record: Users of the Lenovo Yoga 7 2-in-1 16AKP10 laptop. Platform-
specific / driver-specific scope.

**Step 8.2: Determine trigger conditions**
Record: The bug triggers on every boot — the bass speakers are
misconfigured during codec initialization. Every user of this laptop is
affected every time they use audio. Not a rare condition or timing-
dependent race.

**Step 8.3: Determine failure mode severity**
Record: Bass speakers are not configured and speaker volume cannot be
controlled. This is a persistent, user-visible functional defect.
Severity: MEDIUM — not a crash or security issue, but a real hardware
functionality problem that affects every boot.

**Step 8.4: Calculate risk-benefit ratio**
Record:
- **Benefit**: HIGH for affected users — restores proper speaker
  functionality on their laptop.
- **Risk**: VERY LOW — one table entry, exact codec-SSID match, reuses a
  well-tested fixup already used by 7+ other models. Zero risk to other
  hardware.
- **Ratio**: Strongly favorable.

---

## Phase 9: Final Synthesis

**Step 9.1: Compile the evidence**

Evidence FOR backporting:
- Real user-facing bug documented in kernel bugzilla (#221210)
- One-line, exact-match hardware quirk — minimal change
- Reuses `ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN`, well-tested since
  v6.0 across 7+ Lenovo models
- Maintainer (Takashi Iwai) signed off
- Sibling device `0x391c` already uses the same fixup via same mechanism
- `HDA_CODEC_QUIRK` narrows match to codec SSID — no risk of false
  matches
- Author (Zhang Heng) is an established contributor to this area

Evidence AGAINST backporting:
- Not a crash, security, or data corruption fix (functional audio issue)
- Older LTS trees (v6.12 and below) lack `HDA_CODEC_QUIRK()` — not a
  standalone backport there

Unresolved:
- Bugzilla #221210 contents (blocked by Anubis)
- Lore review discussion (blocked by Anubis)

**Step 9.2: Apply the stable rules checklist**
1. Obviously correct and tested? **YES** — one table entry, same fixup
   used by many devices, maintainer sign-off.
2. Fixes a real bug that affects users? **YES** — broken bass speakers
   and volume control on a shipping laptop.
3. Important issue? **YES** — hardware functionality completely broken;
   meets hardware quirk exception.
4. Small and contained? **YES** — 1 line, 1 file.
5. No new features or APIs? **YES** — data table entry only.
6. Can apply to stable trees? **YES** — clean apply on v6.13+ trees that
   have `HDA_CODEC_QUIRK`. Trivially clean on v6.18+/v6.19+.

**Step 9.3: Check for exception categories**
Record: This is a **hardware quirk/workaround** — explicitly listed as
an exception category that is automatically YES for stable.
Specifically, it is an **audio codec quirk** (`HDA_CODEC_QUIRK` entry in
`alc269_fixup_tbl`).

**Step 9.4: Make the decision**
This is a textbook stable backport: a single-line audio codec quirk for
an existing driver, fixing broken speakers on a specific laptop, using a
well-established fixup. It should be backported to stable trees that
already have `HDA_CODEC_QUIRK()` support (v6.13+), with special ease on
v6.18.y and v6.19.y where the sibling entry provides clean context.

---

## Verification

- [Phase 1] Parsed tags from `git show 7bae956cac043`: confirmed Link to
  bugzilla #221210, SOBs from Zhang Heng and Takashi Iwai (ALSA
  maintainer). No Fixes/Reported-by/Cc:stable tags.
- [Phase 2] Diff analysis: confirmed exactly 1 line added —
  `HDA_CODEC_QUIRK(0x17aa, 0x391d, ...)` in `alc269_fixup_tbl[]`.
  Diffstat: `1 file changed, 1 insertion(+)`.
- [Phase 2] Read fixup function at line 3428: confirmed
  `alc287_fixup_yoga9_14iap7_bass_spk_pin()` applies pin config for NID
  0x17, overrides connection list to DACs 0x02/0x03, sets preferred DAC
  pairs.
- [Phase 2] Read `HDA_CODEC_QUIRK` definition in
  `sound/hda/common/hda_local.h`: confirmed it sets `.match_codec_ssid =
  true` for narrow matching.
- [Phase 3] `git blame -L 7574,7576`: confirmed sibling `0x391c` entry
  from `1386d16761c0b5` (J-Donald Tournier, 2025-10-18).
- [Phase 3] `git log --oneline -1 1386d16761c0b5`: confirmed "ALSA:
  hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10".
- [Phase 3] `git tag --contains 3790a3d6dbbc4`: confirmed original Yoga9
  bass-speaker fixup first in released tag v6.0.
- [Phase 3] `git log --oneline -1 504f052aa3435`: confirmed "ALSA:
  hda/realtek: Use codec SSID matching for Lenovo devices".
- [Phase 3] `git tag --contains 504f052aa3435`: confirmed
  `HDA_CODEC_QUIRK` support first in released tag v6.13.
- [Phase 3] `git log --author="Zhang Heng"`: confirmed 6+ prior HDA
  Realtek quirk patches.
- [Phase 5] Grep for `ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN` in quirk
  table: confirmed usage by 0x3801, 0x3869, 0x3882, 0x3891, 0x390d,
  0x391c (7+ models).
- [Phase 5] Grep for `alc287_fixup_yoga9_14iap7_bass_spk_pin`: confirmed
  function definition at line 3428 and fixup array reference at line
  6331.
- [Phase 6] `git tag --contains 7bae956cac043`: confirmed this commit is
  only in v7.0-rc6.
- [Phase 6] `git tag --contains 1386d16761c0b5`: confirmed sibling entry
  first in v6.18.
- [Phase 6] Grep for `0x391d` in current tree: confirmed no existing
  entry (the candidate adds it).
- [Phase 7] `git log --oneline -20 --
  sound/hda/codecs/realtek/alc269.c`: confirmed high churn, all quirk
  additions.
- [Phase 8] Failure mode assessed from commit message and fixup function
  code: non-functional bass speakers and broken volume control. Severity
  MEDIUM.
- UNVERIFIED: Bugzilla #221210 contents (blocked by Anubis bot
  protection).
- UNVERIFIED: Lore patch discussion and any reviewer stable nomination
  (blocked by Anubis).
- UNVERIFIED: Whether a `SND_PCI_QUIRK` adaptation would work for trees
  older than v6.13.

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 39a57d9238497..b83f0c4bec142 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7573,6 +7573,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x38ab, "Thinkbook 16P", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
 	SND_PCI_QUIRK(0x17aa, 0x38b4, "Legion Slim 7 16IRH8", ALC287_FIXUP_CS35L41_I2C_2),
 	HDA_CODEC_QUIRK(0x17aa, 0x391c, "Lenovo Yoga 7 2-in-1 14AKP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
+	HDA_CODEC_QUIRK(0x17aa, 0x391d, "Lenovo Yoga 7 2-in-1 16AKP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	SND_PCI_QUIRK(0x17aa, 0x38b5, "Legion Slim 7 16IRH8", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x17aa, 0x38b6, "Legion Slim 7 16APH8", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x17aa, 0x38b7, "Legion Slim 7 16APH8", ALC287_FIXUP_CS35L41_I2C_2),
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] ASoC: amd: acp: add ASUS HN7306EA quirk for legacy SDW machine

[Sasha Levin]

From: Hasun Park <hasunpark@gmail.com>

[ Upstream commit 2594196f4e3bd70782e7cf1e22e3e398cdb74f78 ]

Add a DMI quirk entry for ASUS HN7306EA in the ACP SoundWire legacy
machine driver.

Set driver_data to ASOC_SDW_ACP_DMIC for this board so the
platform-specific DMIC quirk path is selected.

Signed-off-by: Hasun Park <hasunpark@gmail.com>
Link: https://patch.msgid.link/20260319163321.30326-1-hasunpark@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: Subject Line**
Record: [ASoC: amd: acp] [add] [DMI quirk for ASUS HN7306EA to select
ACP DMIC path in legacy SoundWire machine driver]

**Step 1.2: Tags**
Record:
- `Signed-off-by: Hasun Park <hasunpark@gmail.com>` — author/contributor
- `Link:
  https://patch.msgid.link/20260319163321.30326-1-hasunpark@gmail.com` —
  patch submission
- `Signed-off-by: Mark Brown <broonie@kernel.org>` — ASoC subsystem
  maintainer
- No Fixes: tag (expected for hardware quirk additions)
- No Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc: stable
  (absence expected)

**Step 1.3: Body**
Record: The commit explains it adds a DMI quirk entry for the ASUS
HN7306EA board and sets `driver_data` to `ASOC_SDW_ACP_DMIC` so the
platform-specific DMIC quirk path is selected. Without this quirk, the
board's built-in digital microphone will not be enabled through the ACP
SoundWire path. No stack traces, crash reports, or version information
given — this is standard for a board-specific quirk addition.

**Step 1.4: Hidden Bug Fix**
Record: Yes — while framed as "add," this is a hardware enablement fix.
Without the quirk, the DMIC path is not selected, and the microphone
does not function on this specific laptop. Adding board-specific DMI
quirks is the standard Linux mechanism for making specific hardware work
correctly.

===============================================================
PHASE 2: DIFF ANALYSIS
===============================================================

**Step 2.1: Inventory**
Record: 1 file modified: `sound/soc/amd/acp/acp-sdw-legacy-mach.c`, +8
lines, 0 removed. Only the static `soc_sdw_quirk_table[]` data array is
extended with one new entry before the `{}` terminator. Scope: single-
file, single-table-entry, trivially scoped.

**Step 2.2: Code Flow Change**
Record: Before: No DMI match for "ASUSTeK COMPUTER INC." / "HN7306EA" →
the global `soc_sdw_quirk` stays at its default `RT711_JD1` → DMIC path
not selected at line 419. After: DMI match sets `soc_sdw_quirk =
ASOC_SDW_ACP_DMIC` via `soc_sdw_quirk_cb()` → at line 419,
`soc_sdw_quirk & ASOC_SDW_ACP_DMIC` is true → `dmic_num = 1` →
`create_dmic_dailinks()` is called at line 454, enabling the built-in
digital microphone.

Verified code path from file:

```419:420:sound/soc/amd/acp/acp-sdw-legacy-mach.c
        if (soc_sdw_quirk & ASOC_SDW_ACP_DMIC || mach_params->dmic_num)
                dmic_num = 1;
```

```450:457:sound/soc/amd/acp/acp-sdw-legacy-mach.c
        if (dmic_num > 0) {
                if (ctx->ignore_internal_dmic) {
                        dev_warn(dev, "Ignoring ACP DMIC\n");
                } else {
                        ret = create_dmic_dailinks(card, &dai_links,
&be_id, 0);
                        if (ret)
                                return ret;
                }
```

**Step 2.3: Bug Mechanism**
Record: Category: Hardware workaround / DMI quirk table entry. The board
requires `ASOC_SDW_ACP_DMIC` to be set so the DMIC DAI link is created.
Without it, the standard default (`RT711_JD1`) does not enable the DMIC
path.

**Step 2.4: Fix Quality**
Record: Obviously correct — follows the exact same struct pattern as
every other entry in the table (AMD, Dell, Lenovo). Minimal and
surgical: 8 lines of pure static data. Zero regression risk for other
machines: only fires when both `DMI_BOARD_VENDOR == "ASUSTeK COMPUTER
INC."` AND `DMI_PRODUCT_NAME == "HN7306EA"` match.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: Blame**
Record: `git blame` confirms the quirk table was introduced by
`2981d9b0789c44` (Vijendar Mukunda, 2024-11-13, "ASoC: amd: acp: add
soundwire machine driver for legacy stack") with just one entry (AMD
Birman-PHX). Dell entries added by `4bb5b6f13fd83b` (2025-02-07) and
`3254959b4dd065` (2025-09-03). Lenovo entries added by `aa7b7452bb742f`
(2026-02-18). The infrastructure for `ASOC_SDW_ACP_DMIC` and the DMIC
path has existed since the driver was created.

**Step 3.2: Fixes Tag**
Record: No Fixes: tag present — not applicable for a quirk addition.

**Step 3.3: File History**
Record: 13 commits to this file since creation. Other DMI quirk
additions (Dell, Lenovo) follow the identical pattern. This ASUS commit
is standalone — not part of a series.

**Step 3.4: Author**
Record: `git log --author='Hasun Park'` returns empty for
`sound/soc/amd/` — this appears to be an external contributor (likely
owns the hardware). The patch was merged by Mark Brown, the ASoC
subsystem maintainer, which is a strong quality endorsement.

**Step 3.5: Dependencies**
Record: No dependencies. The `ASOC_SDW_ACP_DMIC` constant (`BIT(5)` in
`soc_amd_sdw_common.h`), the `soc_sdw_quirk_cb` callback, and the DMIC
path all exist since the driver's introduction in v6.13. Fully self-
contained.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1-4.4:** Record: The `Link:` tag provides the patch message ID.
Direct access to lore.kernel.org and patch.msgid.link was blocked by bot
protection (Anubis). The patch was merged by Mark Brown directly. No
NAKs or concerns are evidenced (the commit reached mainline). Could not
verify explicit stable nominations or review comments from primary
sources.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: Key Functions**
Record: No function bodies modified — only the `soc_sdw_quirk_table[]`
static data. Consumers: `soc_sdw_quirk_cb()`, `mc_probe()`,
`soc_card_dai_links_create()`, `create_dmic_dailinks()`.

**Step 5.2: Callers**
Record: `soc_sdw_quirk_table` is consumed by `dmi_check_system()` at
line 498 in `mc_probe()`, the platform driver `.probe` callback.
`mc_probe()` is registered via `soc_sdw_driver` (line 570) matching
platform device ID `"amd_sdw"`.

**Step 5.3: Callees**
Record: `soc_sdw_quirk_cb()` (line 35) simply assigns `soc_sdw_quirk =
(unsigned long)id->driver_data`. Downstream,
`soc_card_dai_links_create()` checks the bit at line 419 and
conditionally enables DMIC DAI link creation.

**Step 5.4: Call Chain**
Record: PCI probe → `acp63_machine_register()` →
`platform_device_register_data(..., "amd_sdw", ...)` → `mc_probe()` →
`dmi_check_system(soc_sdw_quirk_table)` → `soc_card_dai_links_create()`
→ DMIC enabled if `ASOC_SDW_ACP_DMIC` set. Reachable automatically on
boot for matching AMD SoundWire hardware.

**Step 5.5: Similar Patterns**
Record: `acp-sdw-sof-mach.c` has an analogous `ASOC_SDW_ACP_DMIC` gating
mechanism (lines 29, 312), confirming this is an established subsystem
pattern. The same quirk table pattern is used for Dell and Lenovo
entries in the same file.

===============================================================
PHASE 6: STABLE TREE ANALYSIS
===============================================================

**Step 6.1: File Existence in Stable Trees**
Record: Verified via `git cat-file -e`:
- `stable/linux-6.6.y`: **MISSING** (driver not present)
- `stable/linux-6.12.y`: **MISSING** (driver not present)
- `stable/linux-6.13.y`: **EXISTS** (3 commits to file — base + Dell
  quirks)
- `stable/linux-6.14.y`: **EXISTS** (3 commits to file — base + Dell
  quirks)
- `stable/linux-6.19.y`: **EXISTS** (13 commits — all quirks including
  Lenovo)

The driver and `ASOC_SDW_ACP_DMIC` infrastructure exist in **6.13.y,
6.14.y, and 6.19.y**.

**Step 6.2: Backport Complications**
Record: The patch inserts one entry before the `{}` terminator in
`soc_sdw_quirk_table[]`. In 6.13.y and 6.14.y, the table has fewer
entries (no Lenovo rows), so there will be a minor context offset, but
the append-before-terminator pattern makes this trivially applicable.
Expected: clean apply or trivial context adjustment in all three stable
trees.

**Step 6.3: Related Fixes in Stable**
Record: No HN7306EA-specific fix exists in any stable tree. Other
Dell/Lenovo quirks have been backported to various stable trees,
confirming this class of change is accepted.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: Subsystem**
Record: `sound/soc/amd/acp` — ASoC AMD Audio Co-Processor SoundWire
machine driver. Criticality: IMPORTANT — audio is a critical user-facing
function on laptops, though this is driver/platform-specific, not
universal.

**Step 7.2: Activity**
Record: Actively maintained — 13 commits to this single file since
creation, with regular quirk additions for Dell, Lenovo, and now ASUS.
Mark Brown (ASoC maintainer) actively merges patches.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: Affected Users**
Record: Device-specific — owners of the ASUS HN7306EA (ProArt PX13)
laptop running kernel 6.13+ with the AMD SoundWire audio stack.

**Step 8.2: Trigger Conditions**
Record: Triggers on every boot during driver probe via
`dmi_check_system()`. Every user of this laptop model is affected. No
special configuration or user action required.

**Step 8.3: Failure Mode**
Record: Without the quirk, the built-in digital microphone is not
enabled (the DMIC DAI link is never created). This is a "hardware
doesn't work" issue — microphone non-functional. Severity: MEDIUM-HIGH
for affected users (broken audio input on a laptop is a significant
usability issue).

**Step 8.4: Risk-Benefit Ratio**
Record:
- BENEFIT: High for affected users — enables the laptop's built-in
  microphone
- RISK: Essentially zero — DMI match table entry only triggers on exact
  vendor+product match; 8 lines of pure static data; uses existing
  infrastructure; well-established pattern
- Ratio: Strongly favorable

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: Evidence**

FOR backporting:
- Classic hardware DMI quirk addition — explicitly listed as an allowed
  exception category
- 8 lines, single file, pure static data addition, trivially correct
- Zero regression risk — only affects boards matching exact DMI strings
- Fixes real user issue: broken DMIC (microphone non-functional) on ASUS
  HN7306EA
- Merged by ASoC subsystem maintainer Mark Brown
- Self-contained with no dependencies
- Infrastructure exists in 6.13.y, 6.14.y, and 6.19.y stable trees
- Same pattern as Dell and Lenovo quirks already backported to stable
  trees

AGAINST backporting:
- Only affects a single laptop model (normal for quirks — not a valid
  concern)
- Not a crash/security/corruption fix (but hardware enablement quirks
  are an explicit exception)

UNRESOLVED:
- Could not access lore.kernel.org to verify mailing list review
  discussion
- No primary end-user bug report verified (author is likely the affected
  user)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivial table entry following
   exact same pattern as all existing entries; merged by maintainer
2. Fixes a real bug? **YES** — broken DMIC on ASUS HN7306EA
3. Important issue? **YES** — non-functional microphone on a shipping
   laptop
4. Small and contained? **YES** — 8 lines, one file, one table entry
5. No new features or APIs? **YES** — just a DMI quirk data entry using
   existing code paths
6. Can apply to stable? **YES** — applicable to 6.13.y, 6.14.y, 6.19.y
   with clean or trivial context adjustment

**Step 9.3: Exception Category**
Record: **Hardware quirk/workaround** — This is a DMI quirk table entry
for a specific laptop, which is the textbook example of a stable-
appropriate exception. Dell and Lenovo quirks from the same table have
already been backported.

**Step 9.4: Decision**
This is a trivial, zero-risk DMI quirk table entry that enables the
built-in digital microphone on a specific ASUS laptop model. It falls
squarely into the "hardware quirks and workarounds" exception category
that is explicitly allowed in stable. The fix is 8 lines of pure static
data, uses existing infrastructure, and only affects the exact matching
hardware. The driver and `ASOC_SDW_ACP_DMIC` infrastructure exist in
stable trees 6.13.y, 6.14.y, and 6.19.y.

## Verification

- [Phase 1] Parsed commit message: "add ASUS HN7306EA quirk," tags
  include author SOB and Mark Brown (maintainer) SOB, Link to patch
- [Phase 2] Read `acp-sdw-legacy-mach.c`: verified `ASOC_SDW_ACP_DMIC`
  check at line 419 enables `dmic_num = 1`, which triggers
  `create_dmic_dailinks()` at line 454
- [Phase 2] Grep for `ASOC_SDW_ACP_DMIC`: found at line 29 (log_quirks),
  line 419 (DMIC enablement), and `soc_amd_sdw_common.h` line 28
  (`BIT(5)`)
- [Phase 3] `git blame` lines 41-115: confirmed table origin commit
  `2981d9b0789c44` (2024-11-13), Dell quirks from `4bb5b6f13fd83b` and
  `3254959b4dd065`, Lenovo from `aa7b7452bb742f`
- [Phase 3] `git show 2981d9b0789c44`: confirmed original driver
  introduction creating `acp-sdw-legacy-mach.c` (486 lines)
- [Phase 3] `git log --author='Hasun Park'`: no prior commits found in
  `sound/soc/amd/`
- [Phase 3] `git log --oneline -20`: confirmed 13 commits to file, all
  quirk additions and driver evolution, no prerequisites for this patch
- [Phase 5] Traced call chain in code: `mc_probe()` line 498 calls
  `dmi_check_system(soc_sdw_quirk_table)`, then line 514 calls
  `soc_card_dai_links_create()`, which checks quirk at line 419
- [Phase 5] Grep confirmed analogous `ASOC_SDW_ACP_DMIC` pattern in
  `acp-sdw-sof-mach.c` (established subsystem pattern)
- [Phase 6] `git cat-file -e` across stable trees: file MISSING in 6.6.y
  and 6.12.y; EXISTS in 6.13.y, 6.14.y, 6.19.y
- [Phase 6] `git log stable/linux-6.13.y`: 3 commits (base + Dell
  quirks); `stable/linux-6.14.y`: 3 commits; `stable/linux-6.19.y`: 13
  commits (includes Lenovo)
- [Phase 6] Clean apply expected in all three applicable stable trees —
  trivial table entry append
- [Phase 8] Failure mode verified from code: without quirk,
  `ASOC_SDW_ACP_DMIC` not set → `dmic_num` stays 0 →
  `create_dmic_dailinks()` not called → DMIC non-functional
- UNVERIFIED: Could not access lore.kernel.org or patch.msgid.link
  (blocked by Anubis bot protection) — no reviewer discussion or NAKs
  verified

**YES**

 sound/soc/amd/acp/acp-sdw-legacy-mach.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/amd/acp/acp-sdw-legacy-mach.c b/sound/soc/amd/acp/acp-sdw-legacy-mach.c
index 4f92de33a71a0..2e0f751afe250 100644
--- a/sound/soc/amd/acp/acp-sdw-legacy-mach.c
+++ b/sound/soc/amd/acp/acp-sdw-legacy-mach.c
@@ -111,6 +111,14 @@ static const struct dmi_system_id soc_sdw_quirk_table[] = {
 		},
 		.driver_data = (void *)(ASOC_SDW_CODEC_SPKR),
 	},
+	{
+		.callback = soc_sdw_quirk_cb,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "HN7306EA"),
+		},
+		.driver_data = (void *)(ASOC_SDW_ACP_DMIC),
+	},
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()

[Sasha Levin]

From: Goldwyn Rodrigues <rgoldwyn@suse.de>

[ Upstream commit a85b46db143fda5869e7d8df8f258ccef5fa1719 ]

If overlay is used on top of btrfs, dentry->d_sb translates to overlay's
super block and fsid assignment will lead to a crash.

Use file_inode(file)->i_sb to always get btrfs_sb.

Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the evidence. Here is the complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [btrfs: tracepoints] [get correct / fix] [Fix incorrect
superblock derivation in the `btrfs_sync_file` trace event when
overlayfs is stacked on btrfs]

**Step 1.2: Tags**
- Reviewed-by: Boris Burkov <boris@bur.io> (btrfs developer/reviewer)
- Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com> (author, active
  btrfs contributor)
- Signed-off-by: David Sterba <dsterba@suse.com> (btrfs co-maintainer,
  committer)
- No Fixes: tag (expected for commits under manual review)
- No Reported-by:, Tested-by:, Link:, or Cc: stable tags

Record: Reviewed by btrfs developer, committed by btrfs maintainer. No
Fixes: or Cc: stable (expected for manually reviewed candidates).

**Step 1.3: Commit Body**
Record: Bug: when overlayfs is used on top of btrfs, `dentry->d_sb` in
the tracepoint resolves to the overlay superblock, not btrfs'. The
`btrfs_sb()` inline function then treats the overlay's `s_fs_info` as
`struct btrfs_fs_info *`, and `TP_fast_assign_fsid` dereferences
`fs_info->fs_devices->fsid`—accessing completely invalid memory.
Symptom: kernel crash. Fix: use `file_inode(file)->i_sb` to always get
the btrfs superblock.

**Step 1.4: Hidden Bug Fix**
Record: Not hidden—this is an explicit crash fix. The commit message
directly states "will lead to a crash."

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file changed: `include/trace/events/btrfs.h`. Approximately 6
lines added, 4 removed within the `TP_fast_assign` block of
`TRACE_EVENT(btrfs_sync_file)`. Single-file, surgical fix.

**Step 2.2: Code Flow Change**

Before:
```c
const struct dentry *dentry = file->f_path.dentry;
const struct inode *inode = d_inode(dentry);
TP_fast_assign_fsid(btrfs_sb(file->f_path.dentry->d_sb));
__entry->parent = btrfs_ino(BTRFS_I(d_inode(dentry->d_parent)));
```

After:
```c
struct dentry *dentry = file_dentry(file);
struct inode *inode = file_inode(file);
struct dentry *parent = dget_parent(dentry);
struct inode *parent_inode = d_inode(parent);
dput(parent);
TP_fast_assign_fsid(btrfs_sb(inode->i_sb));
__entry->parent = btrfs_ino(BTRFS_I(parent_inode));
```

Three independent improvements:
1. **Critical crash fix**: `file->f_path.dentry->d_sb` → `inode->i_sb`
   for the fsid assignment
2. **Correctness**: `file->f_path.dentry` → `file_dentry(file)` and
   `d_inode(dentry)` → `file_inode(file)` (overlay-safe helpers)
3. **Safety**: parent dentry now accessed via `dget_parent()`/`dput()`
   (proper reference counting)

Record: Single hunk, tracepoint-only path, three small correctness
improvements.

**Step 2.3: Bug Mechanism**
Verified:
- `btrfs_sb(sb)` returns `sb->s_fs_info` (`fs/btrfs/super.h` line 21–24)
- `TP_fast_assign_fsid(fs_info)` does `memcpy(__entry->fsid,
  fs_info->fs_devices->fsid, BTRFS_FSID_SIZE)` (line 163–170)
- Overlayfs stores `struct ovl_fs *` in `sb->s_fs_info`
  (`fs/overlayfs/ovl_entry.h` line 115–121)
- When overlay sb is passed to `btrfs_sb()`, the returned pointer is not
  a `btrfs_fs_info`; dereferencing `->fs_devices->fsid` accesses invalid
  memory → crash

Record: [Type confusion via wrong superblock] [overlay's `s_fs_info`
interpreted as `btrfs_fs_info *`, then invalid dereference of
`fs_devices->fsid`]

**Step 2.4: Fix Quality**
Record: Obviously correct—this is the only btrfs tracepoint using
`file->f_path.dentry->d_sb`; all others already use `inode->i_sb`. Fix
aligns this tracepoint with the established pattern. Very low regression
risk: changes only tracepoint data assignment code.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Verified via `git blame -L 771,779`:
- The buggy fsid line
  (`TP_fast_assign_fsid(btrfs_sb(file->f_path.dentry->d_sb))`)
  introduced in commit `bc074524e123de` (Jeff Mahoney, 2016-06-09,
  "btrfs: prefix fsid to all trace events")
- `git describe --contains bc074524e123de` → `v4.8-rc1~38^2~1^2~12`
- Bug has been present since **v4.8-rc1** — all currently active stable
  trees are affected

Record: [Bug introduced in bc074524e123de, first in v4.8-rc1, present
since 2016 in all active stable trees]

**Step 3.2: Fixes Tag**
Record: No Fixes: tag present. The implicit target is bc074524e123de.

**Step 3.3: File History**
Verified via `git log --oneline -20 -- include/trace/events/btrfs.h`:
- Related prior fix: `f157dd661339f` ("btrfs: fix NULL dereference on
  root when tracing inode eviction") — a different tracepoint crash fix
  in the same file
- Historical related fix: `de17e793b104d` ("btrfs: fix crash/invalid
  memory access on fsync when using overlayfs") — this fixed the **core
  `btrfs_sync_file()` function** for the same overlayfs class of bug,
  but did NOT fix the tracepoint. The current commit completes that
  work.
- The historical commit includes a full oops trace showing the exact
  crash scenario

Record: [Standalone fix. Historical `de17e793b104d` fixed the fsync
function itself but left the tracepoint buggy. This commit completes
that fix.]

**Step 3.4: Author**
Verified: Goldwyn Rodrigues has 10+ btrfs commits including folio
conversions and core btrfs work. David Sterba is a listed btrfs
maintainer.
Record: [Author is established btrfs contributor from SUSE; committed by
btrfs maintainer]

**Step 3.5: Dependencies**
Verified: `file_dentry()`, `file_inode()`, `dget_parent()`, `dput()` all
exist in v5.15, v6.1, v6.6 stable trees.
Record: [No dependencies. All required helper APIs confirmed present in
stable trees.]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Lore Search**
Record: lore.kernel.org returned Anubis anti-bot challenge — exact patch
thread not verified.

**Step 4.2: Bug Report**
Verified: The historical commit `de17e793b104d` includes a full kernel
oops trace from `btrfs_sync_file` when using overlayfs. This establishes
that overlayfs+btrfs fsync crashes are a known, real-world class of bug.
The current tracepoint fix addresses the remaining instance of the same
pattern.
Record: [Real-world crash reports documented in historical commit
de17e793b104d with full stack trace]

**Step 4.3–4.4: Related Patches / Stable History**
Record: Could not verify lore threads. No evidence of prior stable
selection for this specific tracepoint fix.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
Record: `TRACE_EVENT(btrfs_sync_file)` — specifically its
`TP_fast_assign` block

**Step 5.2: Callers**
Verified: `trace_btrfs_sync_file(file, datasync)` called from exactly
one place: `fs/btrfs/file.c:1578` inside `btrfs_sync_file()`.

**Step 5.3–5.4: Call Chain / Reachability**
Verified complete path:
- `fsync(2)` / `fdatasync(2)` → `do_fsync()` → `vfs_fsync()` →
  `vfs_fsync_range()` → `btrfs_sync_file()` → `trace_btrfs_sync_file()`
- Overlayfs path: `ovl_fsync()` (line 441 of `fs/overlayfs/file.c`) →
  `vfs_fsync_range(upperfile, ...)` → `btrfs_sync_file()` →
  `trace_btrfs_sync_file()`
- The tracepoint body executes only when the `btrfs_sync_file`
  tracepoint is enabled (static key gated)

Record: [Directly reachable from userspace fsync() syscall. Overlayfs
path confirmed via ovl_fsync(). Tracepoint gated by static key.]

**Step 5.5: Similar Patterns**
Verified: `TP_fast_assign_fsid(btrfs_sb(file->f_path.dentry->d_sb))`
appears only once in the entire file — this tracepoint. All other btrfs
tracepoints use `inode->i_sb` or receive `fs_info` directly. This is the
sole inconsistent instance.
Record: [Only tracepoint with this bug pattern; all others already
correct]

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Presence in Stable Trees**
Verified via `git cat-file -p`:
- v5.15: buggy line at line 701 ✓
- v6.1: buggy line at line 766 ✓
- v6.6: buggy line at line 795 ✓

Record: [All active stable trees (v5.15, v6.1, v6.6) contain the exact
buggy line]

**Step 6.2: Backport Complications**
Record: Clean apply expected for recent stable trees — same code
structure, same APIs available. Minor line number offsets only.

**Step 6.3: Duplicate Fixes**
Record: No alternative fix for this tracepoint found in any stable tree.
The historical `de17e793b104d` fixed only the function, not the
tracepoint.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
Record: btrfs filesystem tracepoints — IMPORTANT subsystem. btrfs is
widely used, especially with overlayfs in container environments
(Docker, Podman).

**Step 7.2: Activity**
Record: Active — `include/trace/events/btrfs.h` has seen 20+ recent
commits including other tracepoint crash fixes.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Record: Users running overlayfs on top of btrfs with btrfs tracepoints
enabled. This includes container workloads and debugging/tracing
scenarios on production systems.

**Step 8.2: Trigger Conditions**
Record: Enable `btrfs_sync_file` tracepoint (or all btrfs events) + use
overlayfs on btrfs + any `fsync()`/`fdatasync()` call. Deterministic
when conditions met — not a race.

**Step 8.3: Failure Mode**
Record: Kernel crash / oops from invalid memory access in tracepoint
assignment. Severity: **CRITICAL** when triggered (system crash,
potential data loss from incomplete fsync).

**Step 8.4: Risk-Benefit**
- BENEFIT: HIGH — prevents a deterministic kernel crash in a real,
  userspace-triggerable path
- RISK: VERY LOW — ~10 lines changed in a single tracepoint, using
  established VFS helpers consistent with all other btrfs tracepoints
Record: [Benefit: HIGH, Risk: VERY LOW, Ratio: Excellent for
backporting]

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backporting:
- Fixes a real kernel crash (type confusion → invalid memory access →
  oops)
- Small, surgical fix: ~10 lines in 1 file, 1 tracepoint
- Obviously correct: aligns with how all other btrfs tracepoints handle
  the superblock
- Bug class verified real via historical commit `de17e793b104d` with
  full crash stack trace
- Reviewed by btrfs developer, committed by btrfs maintainer
- Bug present in ALL active stable trees (v5.15, v6.1, v6.6) — confirmed
- All required helper APIs exist in stable trees — confirmed
- No dependencies on other commits
- Overlayfs call path verified to reach the buggy code

AGAINST backporting:
- Tracepoint must be enabled to trigger (narrower population than core
  path bugs)
- No Tested-by: tag

UNRESOLVED:
- Exact lore.kernel.org patch discussion thread (blocked by Anubis)
- Whether unprivileged users can enable this tracepoint
- `git apply --check` not run against stable branches (but same code
  confirmed present)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — consistent with all other
   btrfs tracepoints; maintainer-reviewed
2. Fixes a real bug? **YES** — kernel crash with overlayfs+btrfs+tracing
3. Important issue? **YES** — kernel oops (CRITICAL)
4. Small and contained? **YES** — ~10 lines, single tracepoint
5. No new features/APIs? **YES** — pure bug fix
6. Applies to stable? **YES** — buggy code and required APIs confirmed
   in v5.15/v6.1/v6.6

**Step 9.3: Exception Categories**
Record: Not applicable. This is a standard bug fix, not a device
ID/quirk/DT exception.

**Step 9.4: Decision**
The fix addresses a real, deterministic kernel crash caused by type
confusion when overlayfs is stacked on btrfs. The crash mechanism is
fully verified: `btrfs_sb()` interprets overlay's `s_fs_info` (an
`ovl_fs *`) as `btrfs_fs_info *`, then `TP_fast_assign_fsid`
dereferences `fs_info->fs_devices->fsid` — accessing garbage memory. The
fix is small, obviously correct, consistent with all other btrfs
tracepoints, and has no dependencies. The bug exists in all active
stable trees. The only limiting factor is that tracepoints must be
enabled, but stable kernels are regularly used with tracing enabled for
support and debugging, and a crash in that scenario is unacceptable.

---

## Verification

- [Phase 1] Parsed tags from commit message: Reviewed-by Boris Burkov,
  SOB from David Sterba (btrfs maintainer), SOB from Goldwyn Rodrigues
  (author). No Fixes:, Reported-by:, Link:, Cc: stable.
- [Phase 2] Read `include/trace/events/btrfs.h` lines 163–170: confirmed
  `TP_fast_assign_fsid` does `memcpy(__entry->fsid,
  fs_info->fs_devices->fsid, BTRFS_FSID_SIZE)`
- [Phase 2] Read `include/trace/events/btrfs.h` lines 771–779: confirmed
  pre-fix code uses `file->f_path.dentry->d_sb`
- [Phase 2] Grep confirmed `btrfs_sb()` returns `sb->s_fs_info` in
  `fs/btrfs/super.h` lines 21–24
- [Phase 2] Read `fs/overlayfs/ovl_entry.h` lines 115–121: confirmed
  `OVL_FS(sb)` casts `sb->s_fs_info` to `struct ovl_fs *` — type
  confusion verified
- [Phase 2] Grep confirmed the buggy
  `TP_fast_assign_fsid(btrfs_sb(file->f_path.dentry->d_sb))` is the ONLY
  such pattern in btrfs.h
- [Phase 3] `git blame -L 771,779`: buggy fsid line from
  `bc074524e123de` (Jeff Mahoney, 2016)
- [Phase 3] `git describe --contains bc074524e123de`:
  `v4.8-rc1~38^2~1^2~12` — bug present since v4.8
- [Phase 3] `git show de17e793b104d`: confirmed historical
  overlayfs+btrfs fsync crash with full kernel oops trace; that fix
  addressed only `btrfs_sync_file()`, NOT the tracepoint
- [Phase 3] `git log --oneline --author="Goldwyn Rodrigues" -10 --
  fs/btrfs`: confirmed active btrfs contributor
- [Phase 4] lore.kernel.org: blocked by Anubis — patch thread UNVERIFIED
- [Phase 5] Grep: `trace_btrfs_sync_file` called from exactly
  `fs/btrfs/file.c:1578`
- [Phase 5] Read `fs/overlayfs/file.c` lines 441–464: confirmed
  `ovl_fsync()` → `vfs_fsync_range(upperfile)` call path
- [Phase 6] `git cat-file -p v5.15:include/trace/events/btrfs.h`: buggy
  line at line 701 ✓
- [Phase 6] `git cat-file -p v6.1:include/trace/events/btrfs.h`: buggy
  line at line 766 ✓
- [Phase 6] `git cat-file -p v6.6:include/trace/events/btrfs.h`: buggy
  line at line 795 ✓
- [Phase 6] Verified `file_inode`, `file_dentry`, `dget_parent` present
  in v5.15, v6.1, v6.6 via `git cat-file` grep
- [Phase 8] Failure mode: kernel oops from invalid memory access in
  tracepoint assignment, severity CRITICAL
- UNVERIFIED: Exact lore patch discussion (Anubis blocked); privilege
  requirements for tracepoint enablement; `git apply --check` on stable
  branches

**YES**

 include/trace/events/btrfs.h | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h
index 125bdc166bfed..0864700f76e0a 100644
--- a/include/trace/events/btrfs.h
+++ b/include/trace/events/btrfs.h
@@ -769,12 +769,15 @@ TRACE_EVENT(btrfs_sync_file,
 	),
 
 	TP_fast_assign(
-		const struct dentry *dentry = file->f_path.dentry;
-		const struct inode *inode = d_inode(dentry);
+		struct dentry *dentry = file_dentry(file);
+		struct inode *inode = file_inode(file);
+		struct dentry *parent = dget_parent(dentry);
+		struct inode *parent_inode = d_inode(parent);
 
-		TP_fast_assign_fsid(btrfs_sb(file->f_path.dentry->d_sb));
+		dput(parent);
+		TP_fast_assign_fsid(btrfs_sb(inode->i_sb));
 		__entry->ino		= btrfs_ino(BTRFS_I(inode));
-		__entry->parent		= btrfs_ino(BTRFS_I(d_inode(dentry->d_parent)));
+		__entry->parent		= btrfs_ino(BTRFS_I(parent_inode));
 		__entry->datasync	= datasync;
 		__entry->root_objectid	= btrfs_root_id(BTRFS_I(inode)->root);
 	),
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.12] Bluetooth: hci_sync: annotate data-races around hdev->req_status

[Sasha Levin]

From: Cen Zhang <zzzccc427@gmail.com>

[ Upstream commit b6807cfc195ef99e1ac37b2e1e60df40295daa8c ]

__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:

    hdev->req_status = HCI_REQ_PEND;

However, several other functions read or write hdev->req_status without
holding any lock:

  - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)
  - hci_cmd_sync_complete() reads/writes from HCI event completion
  - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write
  - hci_abort_conn() reads in connection abort path

Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while
hci_send_cmd_sync() runs on hdev->workqueue, these are different
workqueues that can execute concurrently on different CPUs. The plain
C accesses constitute a data race.

Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses
to hdev->req_status to prevent potential compiler optimizations that
could affect correctness (e.g., load fusing in the wait_event
condition or store reordering).

Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information for a comprehensive analysis. Let me
compile the full assessment.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1:** Record: [Bluetooth: hci_sync] [annotate] Add
READ_ONCE/WRITE_ONCE annotations to all concurrent accesses to
`hdev->req_status`.

**Step 1.2:** Record: Tags: `Signed-off-by: Cen Zhang
<zzzccc427@gmail.com>` (author), `Signed-off-by: Luiz Augusto von Dentz
<luiz.von.dentz@intel.com>` (Bluetooth subsystem maintainer). No Fixes:,
Reported-by:, Tested-by:, Reviewed-by:, Link:, or Cc: stable tags
present.

**Step 1.3:** Record: The commit explains that `__hci_cmd_sync_sk()`
sets `hdev->req_status = HCI_REQ_PEND` under `hdev->req_lock`, but other
functions read/write `req_status` without any lock. The separate
workqueues (`hdev->req_workqueue` vs `hdev->workqueue`) execute
concurrently on different CPUs. Failure mode: compiler may fuse loads in
the `wait_event` condition or reorder stores.

**Step 1.4:** Record: This IS a real concurrency fix, not merely
cosmetic. The "annotate" framing understates the correctness
implication: under the Linux kernel memory model, concurrent
unsynchronized plain accesses constitute a data race (undefined
behavior).

## PHASE 2: DIFF ANALYSIS

**Step 2.1:** Record: Files: `net/bluetooth/hci_conn.c` (1 read),
`net/bluetooth/hci_core.c` (1 read), `net/bluetooth/hci_sync.c` (6 reads
+ 4 writes). Total: ~12 line replacements, zero logic changes. Functions
modified: `hci_abort_conn()`, `hci_send_cmd_sync()`,
`hci_cmd_sync_complete()`, `__hci_cmd_sync_sk()`,
`hci_cmd_sync_cancel()`, `hci_cmd_sync_cancel_sync()`. Scope: small,
surgical, single-variable annotation across 3 files.

**Step 2.2:** Record: Every hunk replaces a plain `hdev->req_status`
read with `READ_ONCE(hdev->req_status)` or a plain write with
`WRITE_ONCE(hdev->req_status, value)`. No control flow, logic, or API
changes whatsoever.

**Step 2.3:** Record: Category: data race / synchronization fix.
Mechanism: `hdev->req_status` is shared between:
- The sync command waiter (on `req_workqueue` via `__hci_cmd_sync_sk`)
- The command transmitter (on `workqueue` via
  `hci_send_cmd_sync`/`hci_cmd_work`)
- HCI event completion (`hci_cmd_sync_complete`)
- Cancel paths (`hci_cmd_sync_cancel`, `hci_cmd_sync_cancel_sync`)
- Connection abort (`hci_abort_conn`)

The most critical concern: in `hci_cmd_sync_cancel()` and
`hci_cmd_sync_cancel_sync()`, without WRITE_ONCE, the store to
`req_status = HCI_REQ_CANCELED` could be reordered by the compiler with
the store to `req_result`, leading to the waiter in `__hci_cmd_sync_sk`
seeing `HCI_REQ_CANCELED` but reading a stale `req_result`.

**Step 2.4:** Record: Fix is obviously correct — mechanical replacement
with standard kernel annotations. Zero regression risk. No behavior
change intended.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1:** Record: `git blame` shows:
- Core `req_status` in `hci_sync.c` introduced by `6a98e3836fa207`
  (Marcel Holtmann, 2021-10-27) — "Bluetooth: Add helper for serialized
  HCI command execution"
- `hci_abort_conn()` `req_status` read introduced by `a13f316e90fdb1`
  (Luiz von Dentz, 2023-06-26)
- `hci_send_cmd_sync()` direct `req_status` read from `8bedf130c26538`
  (Luiz von Dentz, 2024-07-01)

**Step 3.2:** Record: No Fixes: tag.

**Step 3.3:** Record: Related: `09b0cd1297b4d` ("Bluetooth: hci_sync:
fix race in hci_cmd_sync_dequeue_once") by same author — a real UAF race
fix in the same subsystem. This patch is standalone.

**Step 3.4:** Record: Cen Zhang has one other Bluetooth commit in this
tree (the race fix above). Luiz Augusto von Dentz is the Bluetooth
subsystem maintainer. Maintainer sign-off provides trust.

**Step 3.5:** Record: No dependencies. The change is self-contained
mechanical annotation. However, backport to older trees needs adaptation
(see Phase 6).

## PHASE 4: MAILING LIST RESEARCH

Record: Lore.kernel.org was inaccessible (Anubis PoW challenge). Could
not verify patch discussion, reviewer feedback, or stable nominations.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1:** Functions: `hci_abort_conn()`, `hci_send_cmd_sync()`,
`hci_cmd_sync_complete()`, `__hci_cmd_sync_sk()`,
`hci_cmd_sync_cancel()`, `hci_cmd_sync_cancel_sync()`.

**Step 5.2:** Verified callers:
- `hci_send_cmd_sync()` ← `hci_cmd_work()` on `hdev->workqueue`
- `hci_cmd_sync_complete()` ← installed as `req_complete_skb` callback,
  reached from HCI event processing
- `hci_abort_conn()` ← connection timeout, management disconnect/unpair
  commands
- `__hci_cmd_sync_sk()` ← core HCI sync command infrastructure (many
  callers)
- Cancel functions ← timeout, send error, power-off, mgmt paths

**Step 5.3-5.4:** Record: All paths reachable during normal Bluetooth
operations (device init, connection setup/teardown, suspend/resume). The
separate workqueue allocation confirmed at `hci_core.c:2604` and
`hci_core.c:2610` — two distinct `alloc_ordered_workqueue()` calls.

**Step 5.5:** Record: The `hci_req_sync_lock` macro exists and IS used
extensively (verified via grep), expanding to
`mutex_lock(&hdev->req_lock)`. It protects the caller-side serialization
of `__hci_cmd_sync_sk`. However, the readers in event/cancel/abort paths
do NOT hold this lock — confirming the race window.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** Verified:
- `6a98e3836fa207` is ancestor of v6.1 ✓ and v6.6 ✓ — `hci_sync.c` with
  plain `req_status` accesses exists in both
- `a13f316e90fdb1` is ancestor of v6.6 ✓ — `hci_abort_conn()`
  `req_status` check exists in v6.6
- `8bedf130c26538` is NOT ancestor of v6.6 — v6.6 uses
  `hci_req_status_pend(hdev)` wrapper in `hci_core.c`
- `hci_sync.c` does NOT exist in v5.15 (verified: `git show
  v5.15:net/bluetooth/hci_sync.c` failed)
- v6.6 and v6.1 `hci_sync.c` both have the same plain `req_status`
  pattern (10 occurrences each, verified)

**Step 6.2:** Record: Minor backport adjustment needed for `hci_core.c`
on v6.6/v6.1 (uses `hci_req_status_pend()` wrapper instead of direct
access). `hci_sync.c` changes should apply with minor context
adjustments.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** Record: `net/bluetooth/` — IMPORTANT subsystem. Used by
laptops, phones, IoT, embedded systems. Not core kernel (mm/vfs/net-core
level), but widely used.

**Step 7.2:** Record: Very active subsystem — 20 recent commits in the
touched files.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Record: All Bluetooth users with `CONFIG_BT`. The affected
functions are on the core HCI command synchronization path.

**Step 8.2:** Record: The race requires concurrent access from separate
workqueues or event completion while a sync command is pending. This is
a realistic scenario during normal Bluetooth operation (connection
attempts, command timeouts, connection aborts).

**Critical nuance on the `wait_event` concern:** I verified the
`___wait_event` macro expands to a `for(;;)` loop that calls
`prepare_to_wait_event()` (an out-of-line function with
`spin_lock`/`spin_unlock`) each iteration. This acts as an implicit
compiler barrier, meaning the compiler cannot cache `req_status` across
iterations. The load fusing risk within `wait_event` is therefore
mitigated in practice by the function-call barrier.

However, the **store reordering concern in cancel paths** is more
legitimate: without WRITE_ONCE, the compiler could reorder
`hdev->req_result = err` and `hdev->req_status = HCI_REQ_CANCELED` in
`hci_cmd_sync_cancel()`, causing the waiter to observe `CANCELED` status
but read a stale `req_result`. The reads in `hci_abort_conn()` and
`hci_send_cmd_sync()` also lack annotation.

**Step 8.3:** Record: Failure mode: Incorrect error propagation via
stale `req_result` reads, potential KCSAN reports. Severity: MEDIUM —
not a guaranteed crash but a real correctness issue that could cause
wrong error codes or unexpected command behavior.

**Step 8.4:** Record: Benefit: LOW-MEDIUM (fixes real LKMM violation,
prevents potential incorrect behavior). Risk: VERY LOW (purely
mechanical annotation). Ratio: favorable.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**

FOR backporting:
- Real data race verified across separate workqueues (`hdev->workqueue`
  vs `hdev->req_workqueue`)
- Readers in event/cancel/abort paths confirmed to NOT hold `req_lock`
- Fix is surgical, mechanical, and zero-risk (READ_ONCE/WRITE_ONCE only)
- Core Bluetooth infrastructure — wide user base
- Maintainer signed off
- Author has established credibility (prior UAF race fix in same
  subsystem)
- Buggy code exists in v6.1 and v6.6 stable trees (verified)
- Store reordering in cancel paths is a legitimate correctness concern
- Under LKMM, these are definitionally data races (bugs)

AGAINST backporting:
- No crash/hang/syzbot/KCSAN report cited
- No Fixes: tag, no Reported-by:
- Commit message frames this as "annotation" not "fix"
- The `wait_event` load fusing risk is partially mitigated by implicit
  compiler barriers from `prepare_to_wait_event()`
- Needs minor adaptation for v6.6/v6.1 (`hci_req_status_pend()` wrapper)
- Practical user-visible impact is unverified

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — mechanical, maintainer-
   committed
2. Fixes a real bug? **YES** — LKMM data race, store reordering concern
   in cancel paths
3. Important issue? **BORDERLINE** — correctness issue but no
   demonstrated crash
4. Small and contained? **YES** — 12 line replacements, 3 files
5. No new features or APIs? **YES**
6. Applies to stable? **YES with minor adjustment** for `hci_core.c`

**Step 9.3:** No exception category applies.

**Step 9.4: Decision**

This is a borderline case. The data race is real per the Linux kernel
memory model, and the fix carries effectively zero regression risk. The
store reordering concern in the cancel paths
(`hci_cmd_sync_cancel`/`hci_cmd_sync_cancel_sync`) is a legitimate
correctness issue — the compiler could reorder the `req_result` and
`req_status` stores, causing the waiter to observe inconsistent state.
However, the most dramatic failure scenario (load fusing in
`wait_event`) is largely mitigated in practice by implicit compiler
barriers.

The fix is small, surgical, and obviously correct. The risk/benefit
ratio strongly favors inclusion. The kernel community's position under
LKMM is that data races are bugs, and this fix addresses real concurrent
accesses on core Bluetooth infrastructure. While no crash report exists,
the potential for incorrect error propagation during command
cancellation is a real functional concern for Bluetooth users.

## Verification

- [Phase 1] Parsed tags: only two Signed-off-by present; no Fixes:,
  Reported-by:, Link:, or Cc: stable
- [Phase 2] Diff: confirmed 12 mechanical READ_ONCE/WRITE_ONCE
  replacements across 3 files, zero logic changes
- [Phase 3] git blame: `6a98e3836fa207` (Marcel Holtmann, 2021-10-27)
  introduced core `req_status` pattern in `hci_sync.c`; `a13f316e90fdb1`
  (2023-06-26) introduced `hci_abort_conn()` access; `8bedf130c26538`
  (2024-07-01) introduced `hci_send_cmd_sync()` direct access
- [Phase 3] `git merge-base --is-ancestor`: confirmed `6a98e3836fa207`
  in v6.1 and v6.6; `a13f316e90fdb1` in v6.6; `8bedf130c26538` NOT in
  v6.6
- [Phase 3] `git show v5.15:net/bluetooth/hci_sync.c` failed — file
  doesn't exist in v5.15
- [Phase 3] Author: `git log --author="Cen Zhang"` found one Bluetooth
  commit: `09b0cd1297b4d` (UAF race fix in same area)
- [Phase 5] Verified separate workqueue allocation at `hci_core.c:2604`
  and `hci_core.c:2610` (two `alloc_ordered_workqueue` calls)
- [Phase 5] Verified `hci_req_sync_lock` macro expands to
  `mutex_lock(&hdev->req_lock)` (`include/net/bluetooth/hci_sync.h:15`);
  it IS used extensively by callers of `__hci_cmd_sync_sk` but NOT held
  by event/cancel/abort paths
- [Phase 5] Verified `wait_event` macro: `___wait_event` expands to
  `for(;;)` loop calling `prepare_to_wait_event()` (out-of-line,
  contains spinlock) — acts as implicit compiler barrier per iteration
- [Phase 6] v6.6 `hci_sync.c`: 10 plain `req_status` accesses confirmed;
  v6.1: 10 plain accesses confirmed
- [Phase 6] v6.6 `hci_core.c`: uses `hci_req_status_pend(hdev)` wrapper,
  not direct access (needs adaptation)
- [Phase 6] v6.6 `hci_conn.c`: plain `req_status` read at line 2934
  confirmed
- [Phase 8] `prepare_to_wait_event()` verified: contains
  `spin_lock_irqsave`/`spin_unlock_irqrestore` — mitigates load fusing
  in `wait_event` loop
- UNVERIFIED: Lore.kernel.org discussion (blocked by Anubis)
- UNVERIFIED: Whether KCSAN specifically reported this data race
- UNVERIFIED: Concrete runtime failure attributable to this specific
  race

**YES**

 net/bluetooth/hci_conn.c |  2 +-
 net/bluetooth/hci_core.c |  2 +-
 net/bluetooth/hci_sync.c | 20 ++++++++++----------
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 0f512c2c2fd3c..6335444331bd9 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -2989,7 +2989,7 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
 	 * hci_connect_le serializes the connection attempts so only one
 	 * connection can be in BT_CONNECT at time.
 	 */
-	if (conn->state == BT_CONNECT && hdev->req_status == HCI_REQ_PEND) {
+	if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		switch (hci_skb_event(hdev->sent_cmd)) {
 		case HCI_EV_CONN_COMPLETE:
 		case HCI_EV_LE_CONN_COMPLETE:
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8ccec73dce45c..0f86b81b39730 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4125,7 +4125,7 @@ static int hci_send_cmd_sync(struct hci_dev *hdev, struct sk_buff *skb)
 		kfree_skb(skb);
 	}
 
-	if (hdev->req_status == HCI_REQ_PEND &&
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
 	    !hci_dev_test_and_set_flag(hdev, HCI_CMD_PENDING)) {
 		kfree_skb(hdev->req_skb);
 		hdev->req_skb = skb_clone(hdev->sent_cmd, GFP_KERNEL);
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 43b36581e336d..bd2f5e646eecf 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -25,11 +25,11 @@ static void hci_cmd_sync_complete(struct hci_dev *hdev, u8 result, u16 opcode,
 {
 	bt_dev_dbg(hdev, "result 0x%2.2x", result);
 
-	if (hdev->req_status != HCI_REQ_PEND)
+	if (READ_ONCE(hdev->req_status) != HCI_REQ_PEND)
 		return;
 
 	hdev->req_result = result;
-	hdev->req_status = HCI_REQ_DONE;
+	WRITE_ONCE(hdev->req_status, HCI_REQ_DONE);
 
 	/* Free the request command so it is not used as response */
 	kfree_skb(hdev->req_skb);
@@ -167,20 +167,20 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
 
 	hci_cmd_sync_add(&req, opcode, plen, param, event, sk);
 
-	hdev->req_status = HCI_REQ_PEND;
+	WRITE_ONCE(hdev->req_status, HCI_REQ_PEND);
 
 	err = hci_req_sync_run(&req);
 	if (err < 0)
 		return ERR_PTR(err);
 
 	err = wait_event_interruptible_timeout(hdev->req_wait_q,
-					       hdev->req_status != HCI_REQ_PEND,
+					       READ_ONCE(hdev->req_status) != HCI_REQ_PEND,
 					       timeout);
 
 	if (err == -ERESTARTSYS)
 		return ERR_PTR(-EINTR);
 
-	switch (hdev->req_status) {
+	switch (READ_ONCE(hdev->req_status)) {
 	case HCI_REQ_DONE:
 		err = -bt_to_errno(hdev->req_result);
 		break;
@@ -194,7 +194,7 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
 		break;
 	}
 
-	hdev->req_status = 0;
+	WRITE_ONCE(hdev->req_status, 0);
 	hdev->req_result = 0;
 	skb = hdev->req_rsp;
 	hdev->req_rsp = NULL;
@@ -665,9 +665,9 @@ void hci_cmd_sync_cancel(struct hci_dev *hdev, int err)
 {
 	bt_dev_dbg(hdev, "err 0x%2.2x", err);
 
-	if (hdev->req_status == HCI_REQ_PEND) {
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		hdev->req_result = err;
-		hdev->req_status = HCI_REQ_CANCELED;
+		WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
 
 		queue_work(hdev->workqueue, &hdev->cmd_sync_cancel_work);
 	}
@@ -683,12 +683,12 @@ void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err)
 {
 	bt_dev_dbg(hdev, "err 0x%2.2x", err);
 
-	if (hdev->req_status == HCI_REQ_PEND) {
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		/* req_result is __u32 so error must be positive to be properly
 		 * propagated.
 		 */
 		hdev->req_result = err < 0 ? -err : err;
-		hdev->req_status = HCI_REQ_CANCELED;
+		WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
 
 		wake_up_interruptible(&hdev->req_wait_q);
 	}
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.12] platform/x86: asus-nb-wmi: add DMI quirk for ASUS ROG Flow Z13-KJP GZ302EAC

[Sasha Levin]

From: Matthew Schwartz <matthew.schwartz@linux.dev>

[ Upstream commit 0198d2743207d67f995cd6df89e267e1b9f5e1f1 ]

The ASUS ROG Flow Z13-KJP GZ302EAC model uses sys_vendor name ASUS
rather than ASUSTeK COMPUTER INC., but it needs the same folio quirk as
the other ROG Flow Z13. To keep things simple, just match on sys_vendor
ASUS since it covers both.

Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260312212246.1608080-1-matthew.schwartz@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the facts verified. Here is the complete analysis:

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [platform/x86: asus-nb-wmi] [add] [Broaden DMI vendor match for
ASUS ROG Flow Z13-KJP GZ302EAC so the existing folio quirk applies]

**Step 1.2: Tags**
- Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> (author)
- Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
- Reviewed-by: Denis Benato <denis.benato@linux.dev>
- Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> (subsystem
  maintainer)
- Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
  (maintainer sign-off)
- Link: https://patch.msgid.link/20260312212246.1608080-1-
  matthew.schwartz@linux.dev
- No Fixes:, Reported-by:, Tested-by:, or Cc: stable tags (expected for
  candidates)

Record: Triple Reviewed-by including subsystem maintainer; strong
quality signal.

**Step 1.3: Body Text**
The GZ302EAC model reports `sys_vendor` as "ASUS" rather than "ASUSTeK
COMPUTER INC." The existing Z13 DMI entry matched only the longer
string, so the GZ302EAC variant never received `quirk_asus_z13`. The fix
broadens the vendor match to "ASUS" to cover both strings.
Record: [Bug] DMI vendor string mismatch prevents quirk application.
[Symptom] Missing folio/tablet and key-remap behavior on this model.
[Version info] None explicit. [Root cause] `sys_vendor` differs across
Z13 variants.

**Step 1.4: Hidden Bug Fix Detection**
Record: This is explicitly a hardware quirk fix — the existing Z13 quirk
fails to match a real hardware variant, causing functional regressions
for that model's users.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: [1 file: `drivers/platform/x86/asus-nb-wmi.c`, +1/-1]
[asus_quirks[] data table, Z13 entry] [Single-file, single-line surgical
fix]

**Step 2.2: Code Flow Change**
Before: The Z13 DMI entry matched `DMI_SYS_VENDOR` substring `"ASUSTeK
COMPUTER INC."` plus `DMI_PRODUCT_NAME` substring `"ROG Flow Z13"`.
After: Same entry matches `DMI_SYS_VENDOR` substring `"ASUS"` plus same
product name.

Verified in `drivers/firmware/dmi_scan.c` lines 864-866 that
`DMI_MATCH()` uses `strstr()` for non-exact matches:

```864:866:drivers/firmware/dmi_scan.c
                        if (strstr(dmi_ident[s],
                                   dmi->matches[i].substr))
                                continue;
```

Since "ASUS" is a substring of "ASUSTeK COMPUTER INC.", all previously-
matching devices continue to match. The broader string also covers
models reporting just "ASUS".
Record: [Widens vendor match safely; existing devices still match;
GZ302EAC now also matches]

**Step 2.3: Bug Mechanism**
Category: Hardware workaround / DMI quirk match fix.

The `quirk_asus_z13` provides:

```153:156:drivers/platform/x86/asus-nb-wmi.c
static struct quirk_entry quirk_asus_z13 = {
        .key_wlan_event = ASUS_WMI_KEY_ARMOURY,
        .tablet_switch_mode = asus_wmi_kbd_dock_devid,
};
```

Without matching, the driver falls back to `quirk_asus_unknown` (line
561), resulting in:
- Side button erroneously triggering WiFi rfkill toggle instead of
  emitting KEY_PROG3
- No tablet mode detection when the folio keyboard is detached

Record: [DMI match failure prevents `quirk_asus_z13` application on
GZ302EAC variant; fix widens vendor match safely]

**Step 2.4: Fix Quality**
Record: Obviously correct — single string change in a data table,
mechanically verifiable via `strstr()` semantics. Product-name match
(`"ROG Flow Z13"`) still constrains the match. Regression risk: very
low.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
`git blame` shows the Z13 DMI entry was introduced by commit
`132bfcd24925d4` (Antheas Kapenekakis, 2025-08-08): "platform/x86: asus-
wmi: Fix ROG button mapping, tablet mode on ASUS ROG Z13".
Record: [Buggy code introduced by `132bfcd24925d4`] [First released in
v6.17]

**Step 3.2: Fixes: tag**
Record: N/A — no Fixes: tag present (expected for candidates).

**Step 3.3: File History**
Recent history shows `132bfcd24925d4` (Z13 quirk) and `7dc6b2d3b5503`
(Zenbook Duo UX8406CA quirk addition — same pattern). The candidate is a
standalone follow-up. No other GZ302 or KJP commits found.
Record: [Related: `132bfcd24925d4` prerequisite only] [Standalone fix]

**Step 3.4: Author**
No prior commits by Matthew Schwartz in this subsystem found in local
history. However, three subsystem-relevant reviewers signed off,
including the maintainer Ilpo Järvinen.
Record: [Author is not a regular contributor] [Maintainer reviewed and
signed off]

**Step 3.5: Dependencies**
`git tag --contains 132bfcd24925d4` confirms the prerequisite is in
v6.17, v6.18, and v6.19. It is NOT in v6.12 or older LTS trees (exit
code 1, empty output). The candidate is only meaningful for trees that
already contain this commit.
Record: [Depends on `132bfcd24925d4`; relevant for v6.17+; irrelevant
for v6.12.y, v6.6.y, v6.1.y, v5.15.y]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.4:**
Lore.kernel.org and patch.msgid.link were inaccessible due to Anubis
anti-bot protection. The commit message itself carries three Reviewed-by
tags and maintainer sign-off, which are strong acceptance signals.
Record: [Lore thread content UNVERIFIED; relying on commit tag signals]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Functions/Data**
Record: `asus_quirks[]` table, `asus_nb_wmi_quirks()`,
`dmi_check_system()`, `dmi_matched()`, `quirk_asus_z13`

**Step 5.2: Callers**
`asus_nb_wmi_quirks()` is the `.detect_quirks` callback in
`asus_nb_wmi_driver`, called from `asus_wmi_register_driver()` during
`asus_nb_wmi_init()` → module initialization. Runs on every boot/module
load for affected hardware.
Record: [Called during normal driver initialization, not a hot path]

**Step 5.3: Callees**
`asus_nb_wmi_quirks()` calls `dmi_check_system(asus_quirks)`. On match,
`dmi_matched()` sets the global `quirks` pointer. This subsequently
affects `asus_nb_wmi_key_filter()` (key remapping) and tablet-switch
initialization in `asus-wmi.c`.
Record: [Quirk drives key event handling and tablet mode detection]

**Step 5.4: Call Chain**
`module_init(asus_nb_wmi_init)` → `asus_wmi_register_driver()` →
platform probe → `wdrv->detect_quirks()` → `asus_nb_wmi_quirks()` →
`dmi_check_system(asus_quirks)` → `dmi_matched()` sets quirks.
Record: [Reachable on every boot on affected hardware]

**Step 5.5: Similar Patterns**
The same file has many similar `DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK
COMPUTER INC.")` entries. The sibling commit `7dc6b2d3b5503` (Zenbook
Duo UX8406CA) shows the same pattern of small, single-entry DMI quirk
additions.
Record: [Standard pattern in this file]

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable Trees**
Verified via `git tag --contains`: The Z13 quirk (commit
`132bfcd24925d4`) exists in v6.17, v6.18, v6.19 and their point
releases. It does NOT exist in v6.12 or earlier LTS trees.
Record: [Relevant for v6.17.y, v6.18.y, v6.19.y ONLY]

**Step 6.2: Backport Complications**
One-line string change in a static data table. The Z13 entry is
identical across v6.17, v6.18, and v6.19.
Record: [Clean apply expected on all relevant trees]

**Step 6.3: Duplicate Fixes**
No evidence of an equivalent fix already shipped in stable.
Record: [No duplicates found]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:**
Record: [platform/x86 — ASUS notebook WMI driver] [PERIPHERAL: affects
specific ASUS laptop hardware, not universal]

**Step 7.2:**
Record: [Actively maintained; steady stream of DMI quirk and key-mapping
updates]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who Is Affected**
Record: [Driver-specific / model-specific: owners of ASUS ROG Flow
Z13-KJP GZ302EAC and any other Z13 variant reporting `sys_vendor` =
"ASUS"]

**Step 8.2: Trigger Conditions**
Record: [Triggers on every boot/module-load on affected hardware; not
timing-dependent, not privilege-dependent]

**Step 8.3: Failure Mode Severity**
Without the quirk: the driver falls back to `quirk_asus_unknown`, so the
side button erroneously toggles WiFi rfkill and tablet mode detection
when the folio keyboard is detached does not work.
Record: [Functional hardware issue; severity MEDIUM for affected users]

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Correct hardware behavior for a real device variant (HIGH for
  those users)
- RISK: 1-line data-only change, still constrained by product-name match
  (VERY LOW)
Record: [Strongly favorable ratio]

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
- FOR: Fixes real DMI matching bug; trivial 1-line change; hardware
  quirk stable exception; triple Reviewed-by including maintainer;
  prerequisite exists in v6.17+; `strstr()` semantics verified; zero
  regression risk to existing devices
- AGAINST: Narrow impact (single model variant); not a
  crash/security/corruption fix
- UNRESOLVED: Lore thread content inaccessible; exact KJP DMI strings
  from external source unverified

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivially verifiable,
   maintainer-reviewed
2. Fixes a real bug? **YES** — hardware quirk not applied to real device
3. Important issue? **YES for affected users** — functional hardware
   regression
4. Small and contained? **YES** — 1 line, 1 file, data-only
5. No new features or APIs? **YES** — extends existing quirk coverage
6. Can apply to stable? **YES** — clean apply on v6.17+ trees

**Step 9.3: Exception Category**
Record: **Hardware quirk/workaround** — explicitly in the "quirks and
workarounds" class suitable for stable.

**Step 9.4: Decision**
This is a textbook hardware quirk fix: a single-line broadening of a DMI
vendor match so that an existing quirk applies to a real hardware
variant. It falls squarely into the stable exception for hardware quirks
and workarounds. The fix is trivially correct (verified via `strstr()`
semantics), carries effectively zero regression risk (product-name match
still constrains it), and has strong review signals. It should be
backported to stable trees v6.17.y, v6.18.y, and v6.19.y (the only trees
containing the prerequisite Z13 quirk commit `132bfcd24925d4`).

---

## Verification

- [Phase 1] Parsed subject/body/tags from commit message; found 3x
  Reviewed-by (Mario Limonciello, Denis Benato, Ilpo Järvinen) plus
  maintainer sign-off
- [Phase 2] Read diff: 1 line changed in `asus_quirks[]` — vendor string
  `"ASUSTeK COMPUTER INC."` → `"ASUS"`
- [Phase 2] Verified `DMI_MATCH()` uses `strstr()` in
  `drivers/firmware/dmi_scan.c` lines 865-866
- [Phase 2] Verified `quirk_asus_z13` at lines 153-156: sets
  `key_wlan_event = ASUS_WMI_KEY_ARMOURY` and `tablet_switch_mode =
  asus_wmi_kbd_dock_devid`
- [Phase 2] Verified fallback: `asus_nb_wmi_quirks()` initializes
  `quirks = &quirk_asus_unknown` (line 561) before `dmi_check_system()`
- [Phase 3] `git blame -L 547,555`: Z13 entry introduced by
  `132bfcd24925d4` (Antheas Kapenekakis, 2025-08-08)
- [Phase 3] `git show 132bfcd24925d4`: original commit is "Fix ROG
  button mapping, tablet mode on ASUS ROG Z13"
- [Phase 3] `git tag --contains 132bfcd24925d4`: present in v6.17,
  v6.18, v6.19 and their point releases
- [Phase 3] `git tag --contains 132bfcd24925d4 | grep v6.12`: empty —
  NOT in v6.12 or older LTS trees
- [Phase 3] `git log --oneline -20 -- drivers/platform/x86/asus-nb-
  wmi.c`: confirmed recent history and similar pattern (`7dc6b2d3b5503`)
- [Phase 4] WebFetch on lore.kernel.org and patch.msgid.link blocked by
  Anubis — lore thread UNVERIFIED
- [Phase 5] Confirmed call chain: `module_init` →
  `asus_wmi_register_driver()` → `.detect_quirks` →
  `asus_nb_wmi_quirks()` → `dmi_check_system()`
- [Phase 6] Z13 quirk only exists in v6.17+; fix irrelevant for v6.12.y
  and older
- [Phase 6] Z13 DMI entry identical across v6.17/v6.18/v6.19; clean
  apply expected
- [Phase 8] Failure mode: wrong quirks on affected hardware (missing key
  remap, missing tablet mode); severity MEDIUM
- UNVERIFIED: Exact DMI output of GZ302EAC (claim from commit message
  only)
- UNVERIFIED: Lore discussion content, stable nominations by reviewers,
  any NAKs

**YES**

 drivers/platform/x86/asus-nb-wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index a38a65f5c550d..b4677c5bba5b4 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -548,7 +548,7 @@ static const struct dmi_system_id asus_quirks[] = {
 		.callback = dmi_matched,
 		.ident = "ASUS ROG Z13",
 		.matches = {
-			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUS"),
 			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Flow Z13"),
 		},
 		.driver_data = &quirk_asus_z13,
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] srcu: Use irq_work to start GP in tiny SRCU

[Sasha Levin]

From: Joel Fernandes <joelagnelf@nvidia.com>

[ Upstream commit a6fc88b22bc8d12ad52e8412c667ec0f5bf055af ]

Tiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(),
which acquires the workqueue pool->lock.

This causes a lockdep splat when call_srcu() is called with a scheduler
lock held, due to:

  call_srcu() [holding pi_lock]
    srcu_gp_start_if_needed()
      schedule_work() -> pool->lock

  workqueue_init() / create_worker() [holding pool->lock]
    wake_up_process() -> try_to_wake_up() -> pi_lock

Also add irq_work_sync() to cleanup_srcu_struct() to prevent a
use-after-free if a queued irq_work fires after cleanup begins.

Tested with rcutorture SRCU-T and no lockdep warnings.

[ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_work
to start process_srcu()" ]

Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile the full assessment.

===============================================================
## PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

### Step 1.1: PARSE THE SUBJECT LINE
Record: [srcu] [Use] [irq_work to defer schedule_work() in Tiny SRCU
grace-period start to avoid lockdep splat from pi_lock vs pool->lock
ordering]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by:** Joel Fernandes <joelagnelf@nvidia.com> (author)
- **Reviewed-by:** Paul E. McKenney <paulmck@kernel.org> (RCU co-
  maintainer, original Tiny SRCU author)
- **Signed-off-by:** Boqun Feng <boqun@kernel.org> (RCU
  maintainer/committer)
- No `Fixes:` tag (expected — this is why we're reviewing)
- No `Cc: stable@vger.kernel.org` (expected)
- No `Reported-by:` tag
- No `Link:` tag

Record: Strong maintainer endorsement — reviewed by Paul McKenney (RCU
authority), committed by Boqun Feng (RCU maintainer). Queued into
`fixes.v7.0-rc4` branch (verified via mail-archive). No syzbot or
external bug reporter.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit describes two bugs:

**Bug 1 (lockdep/lock ordering):** `srcu_gp_start_if_needed()` calls
`schedule_work()`, which acquires workqueue `pool->lock`. When
`call_srcu()` is invoked while holding the scheduler `pi_lock`, this
creates a lock ordering inversion:
- Path A: `call_srcu()` [holding `pi_lock`] → `schedule_work()` →
  `pool->lock`
- Path B: `workqueue_init()`/`create_worker()` [holding `pool->lock`] →
  `wake_up_process()` → `try_to_wake_up()` → `pi_lock`

**Bug 2 (UAF prevention):** With the new irq_work mechanism,
`irq_work_sync()` must be added to `cleanup_srcu_struct()` to prevent a
use-after-free if a queued irq_work fires after cleanup begins.

Testing: rcutorture SRCU-T with no lockdep warnings.

Record: [Lock ordering inversion between pi_lock and workqueue
pool->lock] [Lockdep splat, potential deadlock] [No specific version
information] [Root cause: schedule_work() acquires pool->lock from
call_srcu() context that may hold pi_lock]

### Step 1.4: DETECT HIDDEN BUG FIXES
Record: [Not hidden — explicitly describes a lockdep-detected lock
ordering bug and a UAF risk in cleanup. The UAF aspect is specific to
the new irq_work mechanism being introduced by the same commit.]

===============================================================
## PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

### Step 2.1: INVENTORY THE CHANGES
- `include/linux/srcutiny.h`: +4 lines (add `irq_work_types.h` include,
  `struct irq_work srcu_irq_work` field, function declaration, static
  initializer entry)
- `kernel/rcu/srcutiny.c`: +18/-1 lines (add `irq_work.h` include,
  `init_irq_work()` in init, `irq_work_sync()` in cleanup, new
  `srcu_tiny_irq_work()` function, change `schedule_work()` to
  `irq_work_queue()`)
- Total: ~22 lines added, 1 line changed
- Functions modified: `init_srcu_struct_fields()`,
  `cleanup_srcu_struct()`, `srcu_gp_start_if_needed()`
- New function: `srcu_tiny_irq_work()`

Record: [2 files, +22/-1, single-subsystem, well-contained surgical fix]

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
- **Before:** `srcu_gp_start_if_needed()` directly calls
  `schedule_work(&ssp->srcu_work)` when `srcu_init_done`. This acquires
  `pool->lock` synchronously in whatever context the caller is running.
- **After:** `irq_work_queue(&ssp->srcu_irq_work)` is called instead.
  The irq_work handler `srcu_tiny_irq_work()` later calls
  `schedule_work()`, breaking the direct lock nesting from the
  `call_srcu()` call site.
- **Cleanup:** `irq_work_sync()` is added before `flush_work()` in
  `cleanup_srcu_struct()` to ensure no deferred irq_work runs after the
  struct begins teardown.
- **Init:** `init_irq_work()` is added in `init_srcu_struct_fields()`.

Record: [Normal GP-start path changed from synchronous schedule_work()
to deferred irq_work hop. Cleanup path gets irq_work synchronization.
Init path gets irq_work initialization.]

### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **(b) Synchronization / Lock ordering** (lockdep-detected
circular dependency between `pi_lock` and `pool->lock`), plus **(d)
Memory safety** — UAF prevention in the cleanup path for the newly
introduced irq_work.

Record: [Lock ordering inversion (potential deadlock) detected by
lockdep. The UAF prevention is specific to the irq_work mechanism
introduced by this same commit, not a pre-existing UAF in old code.]

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct:** Yes. irq_work is specifically designed for
  deferring work from contexts where direct scheduling is unsafe. This
  is the same pattern used in Tree RCU (referenced by the commit
  message).
- **Minimal/surgical:** Yes. ~22 lines, two files, all within the Tiny
  SRCU subsystem.
- **Regression risk:** Very low. The `irq_work` mechanism is mature. The
  functional behavior is identical (same `schedule_work()` happens, just
  deferred slightly). The `irq_work_sync()` + `flush_work()` ordering in
  cleanup is a standard pattern used elsewhere in the kernel.
- **Red flags:** None. `EXPORT_SYMBOL_GPL(srcu_tiny_irq_work)` is
  slightly unusual for a callback but harmless (needed for module
  builds).

Record: [Fix is obviously correct, minimal, low regression risk.
Standard irq_work deferral pattern, well-established in RCU subsystem]

===============================================================
## PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

### Step 3.1: BLAME THE CHANGED LINES
The direct `schedule_work(&ssp->srcu_work)` call in
`srcu_gp_start_if_needed()` was introduced by commit `1a893c711a600`
("srcu: Provide internal interface to start a Tiny SRCU grace period")
by Paul E. McKenney, dated 2020-11-13. This first appeared in release
`v5.12` (verified via `git tag --contains`, earliest non-next tag would
be p-5.15).

However, the original `call_srcu()` function called `schedule_work()`
even before that refactor — the lock ordering issue has existed since
Tiny SRCU was created.

Record: [Buggy schedule_work() path introduced in 1a893c711a600 (v5.12
era). Present in all stable trees from v5.15 onward.]

### Step 3.2: FOLLOW THE FIXES: TAG
N/A — no `Fixes:` tag present (expected).

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Recent srcutiny.c history shows:
- `e6a43aeb71852` - Remove preempt_disable/enable() in
  srcu_gp_start_if_needed() (recent)
- `da2ac5623716c` - Make Tiny SRCU able to operate in preemptible
  kernels (v6.15+, PREEMPT_LAZY)
- `65b4a59557f6f` - Make Tiny SRCU explicitly disable preemption (v6.12)

The PREEMPT_LAZY change (`da2ac5623716c`, first in v6.15) is
significant: it allows Tiny SRCU to run on preemptible kernels, making
the lock ordering issue more practically relevant than on the
traditional non-preemptible UP configs.

No duplicate irq_work fix for Tiny SRCU was found in the tree. This is
standalone.

Record: [Related to PREEMPT_LAZY enablement. Standalone fix. No
prerequisites beyond existing code.]

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Joel Fernandes is a well-known RCU contributor at NVIDIA with multiple
RCU commits. The fix is reviewed by Paul McKenney (original Tiny SRCU
author) and committed by Boqun Feng (RCU maintainer).

Record: [Joel Fernandes is a regular RCU contributor. Fix has strong
maintainer endorsement.]

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Key backport consideration: The `#include <linux/irq_work_types.h>` in
the header requires this file to exist. Verified that `irq_work_types.h`
was introduced in commit `c809f081fe400` ("irqwork: Move data struct to
a types header") and first appeared in **v6.19** only. It does NOT exist
in v6.18, v6.15, v6.12, v6.6, v6.1, or v5.15. For older stable trees,
the include would need to be changed to `<linux/irq_work.h>` — a trivial
mechanical adaptation.

The `__SRCU_STRUCT_INIT` macro has different argument counts across
versions:
- v5.15: 2 args `(name, __ignored)`
- v6.6: 3 args `(name, __ignored, ___ignored)`
- current: 4 args `(name, __ignored, ___ignored, ____ignored)`

This means the static initializer addition `.srcu_irq_work = { .func =
srcu_tiny_irq_work }` would need to go into the appropriate macro
variant for each stable tree. This is a minor mechanical conflict.

Record: [Standalone logically. Backport needs: 1) `irq_work_types.h` →
`irq_work.h` for trees < v6.19, 2) minor `__SRCU_STRUCT_INIT` macro
adaptation. These are mechanical, not logical, changes.]

===============================================================
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

### Step 4.1: SEARCH LORE.KERNEL.ORG FOR THE PATCH DISCUSSION
Lore was blocked (Anubis anti-bot), but the discussion was found on
mail-archive.com at:
https://www.mail-archive.com/linux-
kernel@vger.kernel.org/msg2619639.html

Key findings from the discussion:
- The patch was dated March 23, 2026
- Boqun Feng queued it into `fixes.v7.0-rc4` branch (the RCU **fixes**
  branch, not features)
- Paul McKenney's `Reviewed-by` was provided in an off-list discussion
- No NAKs, no concerns raised
- No explicit stable nomination by reviewers in the visible thread

Record: [Lore discussion found on mail-archive mirror. Queued into fixes
branch by RCU maintainer. No objections. No explicit Cc: stable
discussion visible.]

### Step 4.2: SEARCH FOR THE BUG REPORT
No external bug report. Found during development/testing. The lockdep
splat is reproducible with rcutorture SRCU-T.

Record: [Found during testing, reproducible with rcutorture]

### Step 4.3: CHECK FOR RELATED PATCHES AND SERIES
The commit message references Boqun Feng's similar fix "rcu: Use an
intermediate irq_work to start process_srcu()" which applies the same
pattern to Tree SRCU. This confirms the pattern is well-established.

Record: [Companion to Boqun's Tree SRCU irq_work fix. Same pattern.]

### Step 4.4: CHECK STABLE MAILING LIST HISTORY
No stable-specific discussion found.

Record: [No stable-specific discussion found]

===============================================================
## PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Modified: `init_srcu_struct_fields()`, `cleanup_srcu_struct()`,
`srcu_gp_start_if_needed()`
New: `srcu_tiny_irq_work()`

### Step 5.2: TRACE CALLERS
`srcu_gp_start_if_needed()` is called from:
1. `call_srcu()` — widely used across the kernel
2. `start_poll_synchronize_srcu()` — used by rcutorture and others

`call_srcu()` callers (verified via grep, 14+ call sites in .c files):
- `virt/kvm/kvm_main.c`
- `mm/mmu_notifier.c`
- `block/blk-mq.c`, `block/blk-mq-tag.c`
- `kernel/events/uprobes.c`
- `fs/tracefs/event_inode.c`
- `fs/dlm/midcomms.c`, `fs/dlm/lowcomms.c`
- `drivers/gpio/gpiolib.c`
- Plus the RCU subsystem itself

**Important caveat:** On TINY_SRCU kernels, only the Tiny SRCU
`call_srcu()` is linked. TINY_SRCU requires `TINY_RCU`, which requires
`!SMP` (UP systems). On older stable trees (v6.12 and before), it
additionally requires `!PREEMPTION`. On v6.15+, PREEMPT_LAZY allows Tiny
SRCU to operate on preemptible (but still UP) kernels.

Record: [Wide caller surface for call_srcu() in general. On TINY_SRCU,
limited to UP kernels. On v6.15+ with PREEMPT_LAZY, the lock ordering
issue becomes more practically relevant.]

### Step 5.3: TRACE CALLEES
`srcu_gp_start_if_needed()` → `schedule_work()` (before) or
`irq_work_queue()` (after)
`srcu_tiny_irq_work()` → `schedule_work()`
`cleanup_srcu_struct()` → `irq_work_sync()` (new) → `flush_work()`
(existing)

Record: [Standard irq_work deferral pattern]

### Step 5.4: FOLLOW THE CALL CHAIN
`call_srcu()` is a generic kernel API. On TINY_SRCU builds, any code
path that invokes `call_srcu()` while holding scheduler locks (like
`pi_lock`) can trigger the lockdep splat. The kernel's scheduler code
does hold `pi_lock` during task wakeups, and subsystems like KVM and
uprobes that use `call_srcu()` can be reached from those contexts.

Record: [Reachable from multiple kernel subsystems. The specific
`pi_lock` → `pool->lock` ordering is mechanically real — verified that
`schedule_work()` → `__queue_work()` takes `pool->lock`, and
`create_worker()` holds `pool->lock` while calling `wake_up_process()`
which takes `pi_lock`.]

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
Multiple irq_work-related fixes exist in the RCU subsystem (`git log
--grep=irq_work -- kernel/rcu/`), confirming this is an established
pattern. Examples:
- `b41642c87716b` "rcu: Fix rcu_read_unlock() deadloop due to IRQ work"
- `f596e2ce1c0f2` "rcu: Use IRQ_WORK_INIT_HARD() to avoid
  rcu_read_unlock() hangs"
- The referenced Boqun patch for Tree SRCU

Record: [Well-established pattern in RCU subsystem]

===============================================================
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
===============================================================

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
Verified directly. All stable trees from v5.15 onward contain the direct
`schedule_work()` call in `srcu_gp_start_if_needed()`:
- **v5.15:** YES — `schedule_work()` at line 168 (with `unsigned short`
  idx types)
- **v6.1:** YES — `schedule_work()` at line 168 (with `unsigned long`
  idx types)
- **v6.6:** YES — `schedule_work()` at line 168
- **v6.12:** YES (would also have `preempt_disable()` from
  `65b4a59557f6f`)
- **v6.15+:** YES (with PREEMPT_LAZY changes)

**Practical impact across versions:**
- **v5.15, v6.1, v6.6:** `TINY_RCU` requires `!PREEMPTION && !SMP`. On
  UP non-preemptible kernels, the lock ordering issue is still
  detectable by lockdep (lockdep tracks lock classes regardless of
  whether locks spin), but a real deadlock hang is less likely since
  spinlocks effectively become preemption disablers on UP.
- **v6.12:** Same as above (`!PREEMPT_RCU && !SMP`, no PREEMPT_LAZY)
- **v6.15+:** PREEMPT_LAZY enables Tiny SRCU on preemptible UP kernels.
  The lock ordering inversion becomes more practically concerning
  because preemption is real.

Record: [Buggy code present in all stable trees v5.15+. Real practical
impact increases on v6.15+ with PREEMPT_LAZY. On older trees, lockdep
still detects the issue.]

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Backport complications identified:
1. `irq_work_types.h` does not exist before v6.19 — must use
   `irq_work.h` instead
2. `__SRCU_STRUCT_INIT` macro has different argument counts: 2 in v5.15,
   3 in v6.6, 4 in current
3. `srcu_gp_start_if_needed()` has `preempt_disable()/enable()` in v6.12
   but not in v6.6 (minor context change)
4. v5.15 uses `unsigned short` for `srcu_idx`/`srcu_idx_max` vs
   `unsigned long` in v6.1+

All of these are minor context/mechanical differences. The core logic
change (replacing `schedule_work()` with `irq_work_queue()`) is
identical.

Record: [Expected backport difficulty: minor conflicts. Needs mechanical
adaptation for include file and macro arguments. Core fix logic applies
cleanly.]

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
No duplicate fix for this specific Tiny SRCU issue found in any stable
tree or branch.

Record: [No related fix already in stable]

===============================================================
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
- **Subsystem:** `kernel/rcu` — SRCU (Sleepable Read-Copy Update), Tiny
  variant
- **Criticality:** CORE — RCU/SRCU is fundamental synchronization
  infrastructure used across the entire kernel. However, the Tiny
  variant specifically targets UP/embedded systems.
- **User base:** Embedded/IoT systems, UP configurations, systems that
  use `CONFIG_TINY_RCU`

Record: [CORE subsystem (RCU). Tiny SRCU variant targets embedded/UP
systems.]

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Actively maintained by Paul McKenney and Boqun Feng. Regular ongoing
development, especially around PREEMPT_LAZY support.

Record: [Active development, strong maintainer oversight]

===============================================================
## PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

### Step 8.1: DETERMINE WHO IS AFFECTED
Systems running with `CONFIG_TINY_SRCU`, which requires
`CONFIG_TINY_RCU`:
- **v6.6 and older:** `!PREEMPTION && !SMP` — UP non-preemptible kernels
  (embedded/IoT)
- **v6.15+:** `!PREEMPT_RCU && !SMP` with PREEMPT_LAZY possible — UP
  kernels that may be preemptible

Record: [Affected: embedded/UP systems using TINY_SRCU. Narrower than
general SMP deployments, but these are real production configurations.]

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- `call_srcu()` invoked while a scheduler lock (`pi_lock`) is held
- This is a realistic scenario in workloads that exercise both scheduler
  and SRCU paths
- On PREEMPT_LAZY kernels (v6.15+), the lock ordering is more
  practically dangerous
- On older trees, lockdep detects the ordering even if an actual hang is
  less likely on UP

Record: [Trigger: call_srcu() while holding scheduler locks.
Reproducible with rcutorture SRCU-T. Realistic in production on
PREEMPT_LAZY.]

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
- **Lockdep splat:** WARNING level — but lockdep splats in core
  synchronization primitives are taken seriously because they indicate a
  real lock ordering design flaw that can hide other real bugs
- **Potential deadlock on PREEMPT_LAZY:** On v6.15+ UP preemptible
  kernels, the lock ordering inversion represents a genuine deadlock
  risk under the right timing conditions — MEDIUM-HIGH
- **Note on the UAF:** The `irq_work_sync()` in cleanup prevents a UAF
  that would exist only with the new irq_work mechanism. This is not a
  pre-existing UAF in old stable trees — it's safety plumbing for the
  new code introduced by this same commit.

Record: [Lockdep splat (WARNING) on all affected trees + potential real
deadlock risk on PREEMPT_LAZY (v6.15+). Severity: MEDIUM-HIGH overall]

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**BENEFIT:**
- Fixes lockdep-detected lock ordering inversion in a core
  synchronization primitive
- On v6.15+: prevents potential real deadlock
- Queued into `fixes` branch (not features) by RCU maintainer —
  maintainers consider this a fix
- Eliminates lockdep noise that can mask real bugs

**RISK:**
- Very low. ~22 lines, well-understood irq_work deferral pattern
- Reviewed by Paul McKenney, tested with rcutorture
- Only adds one extra asynchronous hop to the GP start path
  (functionally equivalent)
- Needs minor mechanical adaptation for older trees (include file, macro
  args)

Record: [Benefit: fixes real lockdep ordering bug in core
infrastructure, prevents potential deadlock on newer stables. Risk: very
low — small, well-reviewed, well-tested.]

===============================================================
## PHASE 9: FINAL SYNTHESIS
===============================================================

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a lockdep-detected lock ordering inversion between `pi_lock` and
  workqueue `pool->lock`
- The lock chain is mechanically verified: `schedule_work()` →
  `__queue_work()` → `pool->lock`, and `create_worker()` →
  `wake_up_process()` → `pi_lock`
- Small, surgical fix (~22 lines, 2 files, single subsystem)
- Reviewed by Paul McKenney (RCU co-creator), committed by Boqun Feng
  (RCU maintainer)
- Queued into `fixes.v7.0-rc4` branch (not features) — maintainers
  consider this a bug fix
- Tested with rcutorture SRCU-T, no lockdep warnings
- Well-understood irq_work deferral pattern already used in Tree RCU
- Buggy `schedule_work()` pattern exists in all stable trees since v5.12
- On v6.15+ with PREEMPT_LAZY, the lock ordering represents a more
  practical deadlock risk
- Lockdep splats in core RCU infrastructure can mask other real bugs

**AGAINST backporting:**
- On older stable trees (v5.15 through v6.12), the lock ordering is
  detectable by lockdep but a real deadlock hang is less likely on UP
  non-preemptible kernels
- Needs minor mechanical backport adaptation (`irq_work_types.h` →
  `irq_work.h`, macro argument counts)
- No external user reports of actual deadlocks
- The UAF prevention in the commit is for the *new* irq_work mechanism,
  not a pre-existing bug
- `CONFIG_TINY_SRCU` is a narrower configuration than general SMP
  deployments

**UNRESOLVED:**
- Could not independently fetch lore.kernel.org (Anubis) — used mail-
  archive mirror instead
- Whether lockdep on UP no-op spinlocks still reports this ordering
  (likely yes, since lockdep tracks lock classes regardless)
- No verified concrete in-tree path that hits Tiny `call_srcu()` while
  specifically holding `pi_lock` (though the ordering conflict is
  mechanically real)

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES — standard irq_work deferral
   pattern, reviewed by Paul McKenney, tested with rcutorture
2. **Fixes a real bug that affects users?** YES — lockdep-detected lock
   ordering inversion. Lockdep warnings in core RCU are treated as
   serious issues by maintainers. More practically dangerous on v6.15+.
3. **Important issue?** YES for v6.15+ (potential deadlock). MEDIUM for
   older trees (lockdep warning in core infrastructure).
4. **Small and contained?** YES — ~22 lines, 2 files, single subsystem
5. **No new features or APIs?** Correct — internal mechanism change only
6. **Can apply to stable trees?** YES with minor mechanical adaptation

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category. This is a standard synchronization/lock-
ordering bug fix.

### Step 9.4: MAKE YOUR DECISION
This commit fixes a real lockdep-detected lock ordering inversion in the
Tiny SRCU implementation — a core kernel synchronization primitive. The
fix is small (~22 lines), well-contained (2 files, single subsystem),
reviewed by the RCU maintainers (Paul McKenney, Boqun Feng), tested with
rcutorture, and uses a well-established irq_work deferral pattern.

The fact that this was queued into the RCU `fixes` branch (not features)
by the maintainers demonstrates they consider it a bug fix, not an
enhancement. Lockdep warnings in core RCU infrastructure are taken
seriously because they indicate real design flaws that can cause
problems under the right conditions and that mask other real bugs.

The practical impact varies across stable trees: on v6.15+ with
PREEMPT_LAZY, the risk is higher (potential real deadlock); on older
trees, it's a lockdep warning that nonetheless indicates a genuine lock
ordering problem. The regression risk is very low given the maturity of
the irq_work mechanism and the surgical nature of the change.

The minor backport adaptations needed (include file, macro arguments)
are mechanical and well within the normal scope of stable backport
adjustments.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Paul E. McKenney, Signed-off-by
  Boqun Feng (RCU maintainers). No Fixes:, no Reported-by:, no Cc:
  stable.
- [Phase 2] Diff analysis: +22/-1 lines across 2 files. Core change:
  `schedule_work()` → `irq_work_queue()` in `srcu_gp_start_if_needed()`,
  plus `irq_work_sync()` in cleanup, `init_irq_work()` in init, new
  `srcu_tiny_irq_work()` handler.
- [Phase 3] git blame: buggy `schedule_work()` introduced in
  `1a893c711a600` by Paul McKenney (2020-11-13). First in release tags
  starting around v5.12.
- [Phase 3] git show `1a893c711a600`: confirmed it created
  `srcu_gp_start_if_needed()` with direct `schedule_work()`.
- [Phase 3] git tag --contains `da2ac5623716c`: PREEMPT_LAZY Tiny SRCU
  enablement first in v6.15.
- [Phase 3] git show v5.15/v6.1/v6.6 srcutiny.c: all contain direct
  `schedule_work()` in `srcu_gp_start_if_needed()`.
- [Phase 3] `irq_work_types.h` (commit `c809f081fe400`) first in v6.19
  only — not in v6.18, v6.15, v6.12, v6.6, v6.1, v5.15. Verified via
  `git show v6.18:include/linux/irq_work_types.h` (exit 128) and `git
  tag --contains`.
- [Phase 3] v5.15 `__SRCU_STRUCT_INIT` has 2 args, v6.6 has 3 args,
  current has 4 args — verified via git show of respective headers.
- [Phase 4] mail-archive.com: found patch discussion at
  https://www.mail-archive.com/linux-
  kernel@vger.kernel.org/msg2619639.html — Boqun queued into
  `fixes.v7.0-rc4`, Paul's Reviewed-by provided off-list. No NAKs.
- [Phase 5] Traced callers: `call_srcu()` used by KVM, mm, block, fs,
  GPIO, uprobes — 14+ call sites in .c files.
- [Phase 5] Verified lock chain: `schedule_work()` → `__queue_work()` →
  `pool->lock` (48 instances of `raw_spin_lock.*pool->lock` in
  workqueue.c). `create_worker()` → `wake_up_process()` → `pi_lock`.
- [Phase 5] Verified irq_work APIs (`init_irq_work`, `irq_work_queue`,
  `irq_work_sync`) exist in v5.15+ via `git show
  v5.15:include/linux/irq_work.h`.
- [Phase 6] Verified Kconfig: v6.6 `TINY_RCU` requires `!PREEMPTION &&
  !SMP`; current requires `!PREEMPT_RCU && !SMP`.
- [Phase 6] No duplicate fix found in any stable tree for this Tiny SRCU
  issue.
- [Phase 7] RCU is CORE subsystem, actively maintained.
- [Phase 8] Severity: lockdep warning on all affected trees; potential
  real deadlock on v6.15+ (PREEMPT_LAZY).
- UNVERIFIED: Could not fetch lore.kernel.org directly (Anubis anti-
  bot); used mail-archive mirror.
- UNVERIFIED: Whether lockdep still reports the ordering on UP
  configurations where spinlocks are effectively no-ops (likely yes,
  lockdep tracks classes regardless).
- UNVERIFIED: Specific in-tree call path where Tiny SRCU `call_srcu()`
  is invoked while holding `pi_lock` (the ordering conflict is
  mechanically real but no specific trigger path was traced end-to-end).

**YES**

 include/linux/srcutiny.h |  4 ++++
 kernel/rcu/srcutiny.c    | 19 ++++++++++++++++++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
index e0698024667a7..313a0e17f22fe 100644
--- a/include/linux/srcutiny.h
+++ b/include/linux/srcutiny.h
@@ -11,6 +11,7 @@
 #ifndef _LINUX_SRCU_TINY_H
 #define _LINUX_SRCU_TINY_H
 
+#include <linux/irq_work_types.h>
 #include <linux/swait.h>
 
 struct srcu_struct {
@@ -24,18 +25,21 @@ struct srcu_struct {
 	struct rcu_head *srcu_cb_head;	/* Pending callbacks: Head. */
 	struct rcu_head **srcu_cb_tail;	/* Pending callbacks: Tail. */
 	struct work_struct srcu_work;	/* For driving grace periods. */
+	struct irq_work srcu_irq_work;	/* Defer schedule_work() to irq work. */
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 	struct lockdep_map dep_map;
 #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
 };
 
 void srcu_drive_gp(struct work_struct *wp);
+void srcu_tiny_irq_work(struct irq_work *irq_work);
 
 #define __SRCU_STRUCT_INIT(name, __ignored, ___ignored, ____ignored)	\
 {									\
 	.srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),	\
 	.srcu_cb_tail = &name.srcu_cb_head,				\
 	.srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp),	\
+	.srcu_irq_work = { .func = srcu_tiny_irq_work },		\
 	__SRCU_DEP_MAP_INIT(name)					\
 }
 
diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
index 3450c3751ef7a..a2e2d516e51b9 100644
--- a/kernel/rcu/srcutiny.c
+++ b/kernel/rcu/srcutiny.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/export.h>
+#include <linux/irq_work.h>
 #include <linux/mutex.h>
 #include <linux/preempt.h>
 #include <linux/rcupdate_wait.h>
@@ -41,6 +42,7 @@ static int init_srcu_struct_fields(struct srcu_struct *ssp)
 	ssp->srcu_idx_max = 0;
 	INIT_WORK(&ssp->srcu_work, srcu_drive_gp);
 	INIT_LIST_HEAD(&ssp->srcu_work.entry);
+	init_irq_work(&ssp->srcu_irq_work, srcu_tiny_irq_work);
 	return 0;
 }
 
@@ -84,6 +86,7 @@ EXPORT_SYMBOL_GPL(init_srcu_struct);
 void cleanup_srcu_struct(struct srcu_struct *ssp)
 {
 	WARN_ON(ssp->srcu_lock_nesting[0] || ssp->srcu_lock_nesting[1]);
+	irq_work_sync(&ssp->srcu_irq_work);
 	flush_work(&ssp->srcu_work);
 	WARN_ON(ssp->srcu_gp_running);
 	WARN_ON(ssp->srcu_gp_waiting);
@@ -177,6 +180,20 @@ void srcu_drive_gp(struct work_struct *wp)
 }
 EXPORT_SYMBOL_GPL(srcu_drive_gp);
 
+/*
+ * Use an irq_work to defer schedule_work() to avoid acquiring the workqueue
+ * pool->lock while the caller might hold scheduler locks, causing lockdep
+ * splats due to workqueue_init() doing a wakeup.
+ */
+void srcu_tiny_irq_work(struct irq_work *irq_work)
+{
+	struct srcu_struct *ssp;
+
+	ssp = container_of(irq_work, struct srcu_struct, srcu_irq_work);
+	schedule_work(&ssp->srcu_work);
+}
+EXPORT_SYMBOL_GPL(srcu_tiny_irq_work);
+
 static void srcu_gp_start_if_needed(struct srcu_struct *ssp)
 {
 	unsigned long cookie;
@@ -189,7 +206,7 @@ static void srcu_gp_start_if_needed(struct srcu_struct *ssp)
 	WRITE_ONCE(ssp->srcu_idx_max, cookie);
 	if (!READ_ONCE(ssp->srcu_gp_running)) {
 		if (likely(srcu_init_done))
-			schedule_work(&ssp->srcu_work);
+			irq_work_queue(&ssp->srcu_irq_work);
 		else if (list_empty(&ssp->srcu_work.entry))
 			list_add(&ssp->srcu_work.entry, &srcu_boot_list);
 	}
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] ALSA: asihpi: avoid write overflow check warning

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit 591721223be9e28f83489a59289579493b8e3d83 ]

clang-22 rightfully warns that the memcpy() in adapter_prepare() copies
between different structures, crossing the boundary of nested
structures inside it:

In file included from sound/pci/asihpi/hpimsgx.c:13:
In file included from include/linux/string.h:386:
include/linux/fortify-string.h:569:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
  569 |                         __write_overflow_field(p_size_field, size);

The two structures seem to refer to the same layout, despite the
separate definitions, so the code is in fact correct.

Avoid the warning by copying the two inner structures separately.
I see the same pattern happens in other functions in the same file,
so there is a chance that this may come back in the future, but
this instance is the only one that I saw in practice, hitting it
multiple times per day in randconfig build.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the data I need. Let me compile the full analysis.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: Subject Line**
Record: [ALSA: asihpi] [avoid] [write overflow check warning from
clang-22 fortify-string in adapter_prepare()]

**Step 1.2: Tags**
- Signed-off-by: Arnd Bergmann <arnd@arndb.de> (author)
- Link:
  https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org
- Signed-off-by: Takashi Iwai <tiwai@suse.de> (ALSA maintainer)
- No Fixes: tag (expected for manual review candidates)
- No Reported-by: tag
- No Cc: stable tag
- No Tested-by: or Reviewed-by:

Record: Author is a highly trusted kernel contributor (Arnd Bergmann).
Maintainer (Takashi Iwai) signed off. No external bug reports.

**Step 1.3: Commit Body**
The commit describes a clang-22 `__write_overflow_field` warning from
`include/linux/fortify-string.h:569`. The `memcpy()` in
`adapter_prepare()` copies between `struct hpi_response` and `struct
hpi_adapter_response`, which are different structure types with
equivalent layouts. The author explicitly states: "the code is in fact
correct." The warning is hit "multiple times per day in randconfig
build." The fix splits one `memcpy` into two field-level copies.

Record: [Bug: build-time fortify warning, not a runtime defect]
[Symptom: -Werror,-Wattribute-warning build failure with clang-22] [Root
cause: FORTIFY_SOURCE cross-field memcpy detection on different struct
types with equivalent layout]

**Step 1.4: Hidden Bug Fix?**
Record: Not a hidden bug fix. The author explicitly confirms the code is
functionally correct. This is purely a compiler warning suppression.

===============================================================
PHASE 2: DIFF ANALYSIS
===============================================================

**Step 2.1: Inventory**
Record: [sound/pci/asihpi/hpimsgx.c: -2/+4 lines, net +2] [Function:
adapter_prepare()] [Scope: single-file, single-function, surgical]

**Step 2.2: Code Flow Change**
Before: One `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter], &hr,
sizeof(rESP_HPI_ADAPTER_OPEN[0]))` — copies the full struct from `hr`
into the adapter open cache.

After: Two memcpys:
1. `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].h, &hr, sizeof(...h))` —
   copies the response header
2. `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].a, &hr.u.ax.info,
   sizeof(...a))` — copies the adapter info payload

This is on the normal initialization path after `HPI_ADAPTER_OPEN`.

Record: [Before: single aggregate memcpy across struct boundaries →
After: two targeted field-level memcpys copying identical data]

**Step 2.3: Bug Mechanism**
Verified struct layouts:
- `struct hpi_response_header`: 12 bytes (u16 size + u8 type + u8
  version + u16 object + u16 function + u16 error + u16 specific_error)
- `struct hpi_response`: inline header fields matching
  `hpi_response_header` + `union { ... union hpi_adapterx_res ax; ... }
  u` at offset 12
- `struct hpi_adapter_response` (packed): `struct hpi_response_header h`
  (12 bytes) + `struct hpi_adapter_res a`
- `union hpi_adapterx_res`: first member is `struct hpi_adapter_res
  info`

The new code copies `sizeof(hpi_response_header)` bytes from `&hr` into
`.h`, then `sizeof(hpi_adapter_res)` bytes from `&hr.u.ax.info` into
`.a`. This is equivalent to the original single copy because the inline
header fields in `hpi_response` are layout-compatible with
`hpi_response_header`, and `hr.u.ax.info` is at offset 12 (same as `.a`
in the packed struct).

Record: [Category: build fix — compiler warning, not runtime bug]
[Mechanism: split memcpy to satisfy FORTIFY_SOURCE field boundary checks
while copying identical data]

**Step 2.4: Fix Quality**
Record: [Obviously correct — verified from struct layouts] [Minimal,
surgical] [Zero regression risk — functionally identical copy] [No API
changes]

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: Blame**
Verified: `git blame -L 584,586` shows the memcpy was introduced in
commit `719f82d3987aa` by Eliot Blennerhassett on 2010-04-21 ("ALSA: Add
support of AudioScience ASI boards"). This code has been in the kernel
since v2.6.35 — present in all active stable trees.

Record: [Introduced: 719f82d3987aa, v2.6.35 era (2010)] [Present in all
stable trees]

**Step 3.2: Fixes Tag**
Record: [N/A — no Fixes: tag present]

**Step 3.3: File History**
Verified: `git log --oneline -20 -- sound/pci/asihpi/hpimsgx.c` shows
very low activity. The only functional fix since the original import was
`7b986c7430a6b` ("Fix potential OOB array access"). Since v5.15, only 2
commits touched this file. Since v6.1, only 1.

Record: [Very stable file, rarely changed] [No prerequisites or series]
[Standalone patch]

**Step 3.4: Author**
Verified: Arnd Bergmann is a prolific kernel contributor who frequently
submits compiler warning/build fixes across the tree. Not the asihpi
subsystem maintainer, but a highly trusted contributor. Takashi Iwai
(ALSA maintainer) applied the patch.

Record: [Arnd Bergmann: trusted cross-tree contributor, specializes in
build fixes] [Takashi Iwai: ALSA maintainer, accepted patch]

**Step 3.5: Dependencies**
Record: [No dependencies — self-contained single memcpy split]

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1-4.4:**
The lore.kernel.org and patch.msgid.link URLs are not accessible due to
anti-bot (Anubis) protection.

Record: [UNVERIFIED: lore discussion content, reviewer feedback, stable
nominations, NAKs]

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: Functions Modified**
Record: [adapter_prepare()]

**Step 5.2: Callers**
Verified: `adapter_prepare()` is called from exactly one place —
`HPIMSGX__init()` at line 719, invoked during
`HPI_SUBSYS_CREATE_ADAPTER`. This is an adapter initialization path
called once per adapter during probe.

Record: [Single call site: HPIMSGX__init() → adapter_prepare()] [Called
during adapter creation/probe, not a hot path]

**Step 5.3-5.4: Callees and Reachability**
The function calls `hpi_init_message_response()`, `hw_entry_point()`,
and `memcpy()`. The call chain is: adapter probe → `hpi_send_recv_ex()`
→ `HPIMSGX__init()` → `adapter_prepare()`. This is reachable from the
ioctl and kernel-side probe path for AudioScience ASI PCI sound cards.

Record: [Probe/initialization path for niche PCI sound hardware]

**Step 5.5: Similar Patterns**
Verified: Similar `memcpy(&cache, &hr, sizeof(cache))` patterns exist
for stream and mixer responses in the same file (lines 608, 621). The
author notes these may trigger similar warnings in the future but
currently only the adapter_prepare instance is hit.

Record: [Similar patterns exist in same file for streams/mixer; only
this one triggers with clang-22 currently]

===============================================================
PHASE 6: STABLE TREE ANALYSIS
===============================================================

**Step 6.1: Code in Stable Trees?**
Verified: The original code was introduced in v2.6.35 (commit
`719f82d3987aa`). Since v6.1, only 1 unrelated commit touched this file.
Since v5.15, only 2. The exact buggy memcpy line exists identically in
all active stable trees.

Record: [Present in all stable trees: v5.15+, v6.1+, v6.6+]

**Step 6.2: Backport Complications**
Record: [Clean apply expected — file barely changed, tiny hunk with
stable surrounding context]

**Step 6.3: Related Fixes**
Record: [No related fixes in stable for this warning]

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: Subsystem**
Record: [sound/pci/asihpi — AudioScience ASI professional audio PCI
boards] [Criticality: PERIPHERAL — niche hardware]

**Step 7.2: Activity**
Record: [Very low activity; mature, rarely touched driver]

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: Who Is Affected**
Record: [Runtime: only users of AudioScience ASI PCI cards. Build:
anyone building CONFIG_SND_ASIHPI (or allmodconfig/randconfig) with
clang-22 and FORTIFY_SOURCE + -Werror]

**Step 8.2: Trigger Conditions**
Record: [Build-time only: clang-22 + CONFIG_FORTIFY_SOURCE + -Werror +
CONFIG_SND_ASIHPI] [Not a runtime trigger]

**Step 8.3: Failure Mode Severity**
Record: [Failure mode: build failure/error] [Runtime severity: NONE —
code is functionally correct] [Build severity: MEDIUM — blocks
compilation under specific toolchain]

**Step 8.4: Risk-Benefit Ratio**
- Benefit: Keeps an existing stable driver buildable with newer compiler
  fortify diagnostics. The author reports hitting this "multiple times
  per day" in randconfig builds.
- Risk: Extremely low — two memcpys copying the same data as one memcpy;
  functionally identical, verified from struct layouts.

Record: [Benefit: LOW-MEDIUM (build fix for newer toolchains)] [Risk:
VERY LOW (trivially correct, behavior-preserving)] [Ratio: favorable]

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: Evidence**

FOR backporting:
- Build fixes are explicitly listed as an allowed stable exception:
  "Fixes for compilation errors or warnings... These are critical for
  users who need to build the kernel"
- Fix is tiny (+4/-2 lines), single-function, obviously correct
- Verified struct layout compatibility confirms the change is behavior-
  preserving
- Author (Arnd Bergmann) is highly trusted; maintainer (Takashi Iwai)
  signed off
- Code exists in all stable trees and patch would apply cleanly
- Stable trees are expected to remain buildable with current toolchains;
  clang versions age into wider use

AGAINST backporting:
- No runtime bug — the code is functionally correct without this patch
- Niche driver (AudioScience ASI PCI cards)
- Only triggers with clang-22, a very recent compiler
- No user reports, no syzbot involvement
- Impact scope is narrow (specific config + specific toolchain)

UNRESOLVED:
- Lore discussion content could not be verified (anti-bot protection)
- Whether reviewers explicitly nominated this for stable

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivially correct from layout
   analysis; tested in randconfig
2. Fixes a real bug that affects users? **YES (build bug)** — prevents
   build failure with affected toolchain
3. Important issue? **MEDIUM** — build failure, not crash/corruption,
   but build fixes are an explicit exception
4. Small and contained? **YES** — 4 lines changed in 1 function
5. No new features or APIs? **YES**
6. Can apply to stable trees? **YES** — identical code in all stable
   trees

**Step 9.3: Exception Categories**
This falls under the **Build Fixes** exception: "Fixes for compilation
errors or warnings, Kconfig dependency fixes, include file fixes — These
are critical for users who need to build the kernel."

**Step 9.4: Decision**

This is a legitimate build fix under the stable exception rules. The
patch is behavior-preserving (verified from struct layout analysis),
trivially correct, and zero-risk. While the impact is narrow (clang-22 +
niche driver), the stable tree policy explicitly allows build fixes
because maintaining buildability with current and evolving toolchains is
a core goal. Compiler versions age into wider use, and preventing build
regressions on stable trees has standalone value. The near-zero
regression risk further supports inclusion.

**Verification:**
- [Phase 1] Parsed all tags: Link, 2x Signed-off-by; no Fixes, Reported-
  by, Cc: stable
- [Phase 2] Diff: single memcpy replaced by two field-level memcpys in
  adapter_prepare(); net +2 lines
- [Phase 2] Struct layout verified: hpi_response_header (12 bytes
  inline), hpi_response has matching inline fields + union at offset 12,
  hpi_adapter_response is packed header.h + adapter_res.a — layouts
  confirmed compatible
- [Phase 3] git blame: code introduced in 719f82d3987aa (2010, v2.6.35
  era), present in all stable trees
- [Phase 3] git log: file barely changed; only 1 commit since v6.1, 2
  since v5.15; no series/dependencies
- [Phase 3] Author verified: Arnd Bergmann, prolific build-fix
  contributor; Takashi Iwai (ALSA maintainer) applied
- [Phase 4] UNVERIFIED: lore.kernel.org discussion blocked by anti-bot
  protection
- [Phase 5] Callers traced: adapter_prepare() called only from
  HPIMSGX__init() (line 719), probe/init path
- [Phase 5] Similar memcpy patterns exist at lines 608, 621 for streams;
  only adapter instance triggers currently
- [Phase 6] Code exists identically in v5.15, v6.1, v6.6; clean apply
  expected
- [Phase 7] Subsystem: sound/pci/asihpi — PERIPHERAL, low activity,
  mature driver
- [Phase 8] Impact: build-time only, clang-22 + FORTIFY_SOURCE +
  -Werror; severity MEDIUM as build fix
- [Phase 8] Risk: VERY LOW — functionally identical change, verified
  from struct layouts

**YES**

 sound/pci/asihpi/hpimsgx.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/sound/pci/asihpi/hpimsgx.c b/sound/pci/asihpi/hpimsgx.c
index b68e6bfbbfbab..ed1c7b7744361 100644
--- a/sound/pci/asihpi/hpimsgx.c
+++ b/sound/pci/asihpi/hpimsgx.c
@@ -581,8 +581,10 @@ static u16 adapter_prepare(u16 adapter)
 		HPI_ADAPTER_OPEN);
 	hm.adapter_index = adapter;
 	hw_entry_point(&hm, &hr);
-	memcpy(&rESP_HPI_ADAPTER_OPEN[adapter], &hr,
-		sizeof(rESP_HPI_ADAPTER_OPEN[0]));
+	memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].h, &hr,
+		sizeof(rESP_HPI_ADAPTER_OPEN[adapter].h));
+	memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].a, &hr.u.ax.info,
+		sizeof(rESP_HPI_ADAPTER_OPEN[adapter].a));
 	if (hr.error)
 		return hr.error;
 
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.1] erofs: add GFP_NOIO in the bio completion if needed

[Sasha Levin]

From: Jiucheng Xu <jiucheng.xu@amlogic.com>

[ Upstream commit c23df30915f83e7257c8625b690a1cece94142a0 ]

The bio completion path in the process context (e.g. dm-verity)
will directly call into decompression rather than trigger another
workqueue context for minimal scheduling latencies, which can
then call vm_map_ram() with GFP_KERNEL.

Due to insufficient memory, vm_map_ram() may generate memory
swapping I/O, which can cause submit_bio_wait to deadlock
in some scenarios.

Trimmed down the call stack, as follows:

f2fs_submit_read_io
  submit_bio                      //bio_list is initialized.
    mmc_blk_mq_recovery
      z_erofs_endio
        vm_map_ram
          __pte_alloc_kernel
            __alloc_pages_direct_reclaim
              shrink_folio_list
                __swap_writepage
                  submit_bio_wait  //bio_list is non-NULL, hang!!!

Use memalloc_noio_{save,restore}() to wrap up this path.

Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Jiucheng Xu <jiucheng.xu@amlogic.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

All verified. Here is the complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: erofs (Enhanced Read-Only File System, compressed I/O
  path)
- **Action verb**: "add" — but the body describes a deadlock fix
- **Summary**: Adds `memalloc_noio_save/restore` scope in BIO completion
  to prevent deadlock during direct decompression

Record: [erofs] [add (really "fix")] [Wraps direct decompression in
GFP_NOIO scope to prevent deadlock in bio completion]

### Step 1.2: Tags
- **Reviewed-by**: Gao Xiang <hsiangkao@linux.alibaba.com> — erofs
  maintainer
- **Signed-off-by**: Jiucheng Xu <jiucheng.xu@amlogic.com> — patch
  author (Amlogic, ARM/Android platform vendor)
- **Reviewed-by**: Chao Yu <chao@kernel.org> — regular erofs reviewer
- **Signed-off-by**: Gao Xiang <hsiangkao@linux.alibaba.com> — committed
  through maintainer tree
- No `Fixes:` tag (expected for commits needing manual review)
- No `Cc: stable@vger.kernel.org` (expected)
- No `Reported-by:` or `Link:` tags
- Notable: Two reviews from subsystem maintainer and key reviewer;
  committed by maintainer

Record: Two senior reviewers (one is the subsystem maintainer). No Fixes
tag. Author is from Amlogic (Android SoC vendor, direct user of
erofs+dm-verity).

### Step 1.3: Commit Body Text
The commit describes a **concrete deadlock scenario** with a trimmed
stack trace:
1. BIO completion runs in process context (e.g., when dm-verity is
   layered on top)
2. EROFS directly calls decompression (not via workqueue) to minimize
   latency
3. Decompression calls `vm_map_ram()` with `GFP_KERNEL`
4. Under memory pressure, `vm_map_ram()` → page allocation → direct
   reclaim → swap writeback → `submit_bio_wait()`
5. Since `bio_list` is already initialized from the parent `submit_bio`,
   the new bio gets queued to `bio_list` but is never drained →
   **deadlock/hang**

Stack trace: `f2fs_submit_read_io → submit_bio → mmc_blk_mq_recovery →
z_erofs_endio → vm_map_ram → __pte_alloc_kernel →
__alloc_pages_direct_reclaim → shrink_folio_list → __swap_writepage →
submit_bio_wait //hang`

Record: Real deadlock in BIO completion path. Trigger: erofs on dm-
verity under memory pressure. Symptom: system hang. Root cause:
GFP_KERNEL allocation inside bio completion context can recurse into
block I/O.

### Step 1.4: Hidden Bug Fix Detection
Despite the subject using "add" rather than "fix", the commit message
describes a real deadlock and provides a concrete stack trace
demonstrating the hang. The fix uses the standard kernel mechanism for
preventing I/O recursion. This is absolutely a bug fix.

Record: Yes, genuine bug fix disguised with "add" verb. The body clearly
describes a deadlock.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 (`fs/erofs/zdata.c`)
- **Lines added**: 3 (1 local variable declaration + 2 API calls)
- **Lines removed**: 0
- **Function modified**: `z_erofs_decompress_kickoff()`
- **Scope**: Single-file, single-function, surgical fix

Record: [fs/erofs/zdata.c: +3/-0 lines] [z_erofs_decompress_kickoff]
[Surgical single-function fix]

### Step 2.2: Code Flow Change
**Before** (line 1494 of current code): When
`z_erofs_decompress_kickoff()` reaches the non-atomic fallthrough path,
it calls `z_erofs_decompressqueue_work(&io->u.work)` directly with no
memory allocation restrictions. Any `GFP_KERNEL` allocation in the call
chain can trigger reclaim I/O.

**After**: The direct call is wrapped:
```c
gfp_flag = memalloc_noio_save();
z_erofs_decompressqueue_work(&io->u.work);
memalloc_noio_restore(gfp_flag);
```
This sets `PF_MEMALLOC_NOIO` on the current task's flags, causing all
allocations in the decompression path to have `__GFP_IO` stripped,
preventing swap/reclaim I/O.

Record: Before: unrestricted GFP_KERNEL allocations during decompression
in bio completion. After: GFP_NOIO scope prevents I/O recursion.

### Step 2.3: Bug Mechanism
**Category**: Deadlock / I/O recursion

**Mechanism**: I verified the full call chain:
- `z_erofs_endio()` (bio completion, line 1668) →
  `z_erofs_decompress_kickoff(q, -1)` → non-atomic branch →
  `z_erofs_decompressqueue_work()` → `z_erofs_decompress_queue()` →
  `z_erofs_decompress_pcluster()` → multiple `GFP_KERNEL` allocations:
  - `kvcalloc(..., GFP_KERNEL | __GFP_NOFAIL)` at lines 1300 and 1304
    for decompressed/compressed pages
  - `kmalloc(..., GFP_KERNEL | __GFP_NOFAIL)` at line 1161 for secondary
    bvecs
  - `erofs_vm_map_ram()` → `vm_map_ram()` → `vb_alloc(size, GFP_KERNEL)`
    at `mm/vmalloc.c:3070` or `alloc_vmap_area(..., GFP_KERNEL, ...)` at
    `mm/vmalloc.c:3078`

Any of these `GFP_KERNEL` allocations can trigger direct reclaim under
memory pressure, which can attempt swap writeback via
`submit_bio_wait()`, and since `bio_list` is active from the parent
`submit_bio()`, the new bio goes to the list but never drains.

Record: [Deadlock] [Bio completion → direct decompression → GFP_KERNEL
allocations (vm_map_ram, kvcalloc) → direct reclaim → swap I/O →
submit_bio_wait hangs because bio_list is active]

### Step 2.4: Fix Quality
- **Obviously correct**: `memalloc_noio_save/restore` is the standard
  kernel API for this exact pattern. It is used extensively in dm, md,
  block, and filesystem layers for the same purpose.
- **Minimal**: 3 lines added, no logic changes, no data structure
  changes.
- **Regression risk**: Very low. The only effect is restricting
  allocations from triggering I/O in this scope. This could mean more
  allocation failures under extreme pressure, but the `__GFP_NOFAIL`
  allocations will still succeed (they just won't trigger I/O for
  reclaim), and `vm_map_ram` already handles allocation failure
  gracefully via retry in `erofs_vm_map_ram()`.
- **No red flags**: No API changes, no locking changes, no new code
  paths.

Record: [Obviously correct, standard kernel pattern] [Very low
regression risk] [Minimal scope]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame Changed Lines
`git blame` on lines 1458-1495 shows:
- `z_erofs_decompress_kickoff()` function structure: commit
  `7865827c432bf9` (Gao Xiang, 2022-01-21) — a code rearrangement
- The direct `z_erofs_decompressqueue_work(&io->u.work)` call at line
  1494: same commit `7865827c432bf9`
- The direct decompression optimization was **originally introduced** by
  commit `648f2de053a88` (Huang Jianan, 2021-03-17): "erofs: use
  workqueue decompression for atomic contexts only"

The original `648f2de053a88` commit first appeared in tag `v5.13`. I
verified:
- `v5.10`: **NOT** ancestor — the buggy direct-call path does not exist
- `v5.15`: **IS** ancestor — the buggy path exists
- `v6.1`: **IS** ancestor
- `v6.6`: **IS** ancestor

Record: Direct decompression path introduced in 648f2de053a88 (v5.13).
Present in v5.15, v6.1, v6.6, v6.12 and later. NOT present in v5.10.

### Step 3.2: Fixes Tag
No `Fixes:` tag present. (Expected for commits requiring manual review.)

### Step 3.3: Related File History
Related commits in the same optimization area:
- `648f2de053a88` (v5.13): Introduced direct decompression in non-atomic
  context
- `7865827c432bf9` (v5.17): Rearranged function, same direct-call logic
- `12d0a24afd9ea` (2023): "Fix detection of atomic context" — 1-line fix
  to atomic check
- `c99fab6e80b76` (2025): "fix atomic context detection when
  !CONFIG_DEBUG_LOCK_ALLOC" — introduced `z_erofs_in_atomic()` helper

The non-atomic direct decompression path has needed **multiple follow-up
fixes**, establishing a pattern that this optimization area is
correctness-sensitive.

No prior `memalloc_noio` fix exists in erofs (verified: `git log
--grep='memalloc_noio' -- fs/erofs` returns empty).

Record: Part of a pattern of fixes to the same direct-decompression
optimization. Standalone fix. No prior NOIO fix in erofs.

### Step 3.4: Author
- Jiucheng Xu from Amlogic — no prior erofs commits found locally,
  likely a first-time contributor from the platform vendor side
- Patch was reviewed by erofs maintainer Gao Xiang and regular reviewer
  Chao Yu, and committed through Gao Xiang's tree
- Amlogic makes ARM SoCs used in Android devices — dm-verity + erofs is
  standard on such platforms

Record: Author is from platform vendor, fix reviewed and committed by
erofs maintainer.

### Step 3.5: Dependencies
The fix is self-contained:
- `memalloc_noio_save/restore` exists in `include/linux/sched/mm.h`
  (verified: 4 occurrences of `memalloc_noio_save` in current tree)
- These helpers have been available since well before v5.15
- The direct decompression call path where the fix applies exists in all
  applicable stable trees (v5.15+)
- No code structure changes needed

Record: No dependencies. Fully self-contained. Can apply standalone to
any tree with the direct-call path.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Lore Discussion
The related commit `12d0a24afd9ea` ("Fix detection of atomic context")
has accessible discussion showing:
- A concrete stack trace from `filemap_fault`/readahead through dm-
  verity into `z_erofs_decompress_kickoff()`, proving the direct
  decompression in bio completion context is a real-world scenario
- The dm-verity + erofs combination is explicitly called out as the
  trigger

The commit was included in erofs rc-fixes targeting mainline, which is
the standard path for critical fixes.

Record: Related discussion confirms real-world dm-verity + erofs
scenario. Fix submitted through maintainer's fixes branch.

### Step 4.2: Bug Report
No explicit `Reported-by:` or `Link:` tags. The stack trace in the
commit message references a concrete scenario (f2fs + mmc + erofs/dm-
verity), indicating real-world observation. The author being from
Amlogic (Android SoC vendor) strongly suggests this was discovered on
production Android devices.

Record: No formal bug report link, but stack trace indicates real
observation on Android platform.

### Step 4.3: Series Context
This is a standalone fix, not part of a dependent series.

Record: Standalone fix.

### Step 4.4: Stable Discussion
No specific stable discussion found for this patch.

Record: No stable-specific discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
Only `z_erofs_decompress_kickoff()` is modified.

### Step 5.2: Callers
`z_erofs_decompress_kickoff()` is called from:
1. **`z_erofs_endio()`** (line 1668) — BIO completion callback. This is
   the problematic path — when bio completion runs in process context
   (dm-verity), this is NOT atomic, and the non-atomic branch takes the
   direct decompression path.
2. **`z_erofs_submit_queue()`** (line 1805) — submit path, called after
   dispatching bios.

### Step 5.3: Callees in the non-atomic path
`z_erofs_decompressqueue_work()` → `z_erofs_decompress_queue()` →
`z_erofs_decompress_pcluster()` which:
- Allocates `decompressed_pages` via `kvcalloc(..., GFP_KERNEL |
  __GFP_NOFAIL)` (line 1300)
- Allocates `compressed_pages` via `kvcalloc(..., GFP_KERNEL |
  __GFP_NOFAIL)` (line 1304)
- Calls decompression algorithm which uses `erofs_vm_map_ram()` →
  `vm_map_ram()` → `vb_alloc(size, GFP_KERNEL)` (mm/vmalloc.c:3070)

All of these allocations can trigger direct reclaim.

### Step 5.4: Reachability
Full verified call chain from userspace:
- Userspace read/page fault on compressed erofs file
- → `z_erofs_read_folio()` (line 1887) or `z_erofs_readahead()` (line
  1910)
- → `z_erofs_runqueue()` → `z_erofs_submit_queue()` → `submit_bio()`
- → bio completion → `z_erofs_endio()` (line 1648)
- → `z_erofs_decompress_kickoff(q, -1)` (line 1668)
- → non-atomic branch → `z_erofs_decompressqueue_work()` → `GFP_KERNEL`
  allocations → deadlock

This is the **primary compressed data read path** for erofs. Any
unprivileged user reading a file from a mounted erofs filesystem can
trigger it.

Record: Critical primary read path. Reachable from unprivileged
userspace file reads.

### Step 5.5: Similar Patterns
`memalloc_noio_save/restore` is used extensively throughout the kernel
(dm, md, block layer) for the same purpose. No existing usage in
`fs/erofs/` — this is the first.

Record: Standard pattern used throughout kernel. First application in
erofs.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Does the buggy code exist in stable trees?
Verified with `git show <version>:fs/erofs/zdata.c | grep`:
- **v5.10**: Direct-call path does **NOT** exist (648f2de053a88 not
  ancestor) → NOT APPLICABLE
- **v5.15**: Direct-call exists at line 802 → **AFFECTED**
- **v6.1**: Direct-call exists at line 1195 → **AFFECTED**
- **v6.6**: Direct-call exists at line 1435 → **AFFECTED**
- **v6.12**: Direct-call exists at line 1373 → **AFFECTED**

Record: Bug affects all active stable trees v5.15 through v6.12. NOT
applicable to v5.10 or older.

### Step 6.2: Backport Complications
The function context has changed across versions:
- v5.15: uses `bool sync` parameter, older `in_atomic() ||
  irqs_disabled()` check
- v6.1: same older check, some structural changes
- v6.6: uses different atomic detection
- v6.12: uses `z_erofs_in_atomic()` helper (from c99fab6e80b76)

However, the **actual fix location** (wrapping the direct
`z_erofs_decompressqueue_work()` call) is consistent across all
versions. The fix should apply with minor context adjustment (fuzz) on
older trees.

`memalloc_noio_save/restore` helpers exist in all these stable baselines
(verified in `include/linux/sched/mm.h`).

Record: Minor context adjustment needed for older stable trees. Fix site
is consistent. Helper APIs available everywhere.

### Step 6.3: Related fixes in stable
No prior `memalloc_noio` fix in erofs exists. The related atomic-context
fixes (`12d0a24afd9ea`, `c99fab6e80b76`) may or may not be in each
stable tree, but they are not prerequisites — they only change which
branch is taken (atomic vs. non-atomic), not the fix itself.

Record: No duplicate fix in stable. Not redundant with existing fixes.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: `fs/erofs` — compressed read-only filesystem
- **Criticality**: IMPORTANT
  - Widely used on Android devices (system/vendor partition)
  - Increasingly used in container/cloud environments (read-only layers)
  - dm-verity + erofs is the default stack on modern Android

Record: [fs/erofs] [IMPORTANT — Android, embedded, containers]

### Step 7.2: Activity Level
Recent `git log -20 -- fs/erofs/zdata.c` shows active development with
regular fixes and improvements. Actively maintained by Gao Xiang.

Record: Active subsystem with regular maintenance.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users of erofs with compressed data who:
- Run erofs on dm-verity (standard on Android)
- Or any other stacking block device where bio completion runs in
  process context
- AND experience memory pressure (common on memory-constrained
  mobile/embedded devices)

Record: Large user population (Android devices, embedded systems with
dm-verity + erofs).

### Step 8.2: Trigger Conditions
- erofs compressed file read (ordinary `read()` or page fault)
- BIO completion in process context (dm-verity provides this)
- Memory pressure sufficient to trigger direct reclaim
- Reclaim attempts swap writeback → `submit_bio_wait` with active
  `bio_list`

This is realistic on Android devices which frequently run under memory
pressure. No privileges needed beyond read access to mounted filesystem.

Record: [Common trigger: ordinary file reads under memory pressure on
Android/dm-verity] [No special privileges needed]

### Step 8.3: Failure Mode Severity
**CRITICAL**: Complete system deadlock/hang. The `submit_bio_wait()`
blocks indefinitely because the bio is queued to the active `bio_list`
but never drained (the draining happens only after the parent bio
completion returns, which is waiting for this one). This renders the
system unresponsive and typically requires a hard reboot.

Record: [System deadlock/hang] [Severity: CRITICAL]

### Step 8.4: Risk-Benefit Ratio
- **BENEFIT**: Very high — prevents a complete system hang on a widely-
  deployed platform configuration
- **RISK**: Very low — 3-line addition using a well-established kernel
  API, no logic changes, no new code paths, no changed return values, no
  API modifications
- **Ratio**: Overwhelmingly favorable

Record: [Benefit: Very High] [Risk: Very Low] [Ratio: Strongly
favorable]

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting:**
- Fixes a real deadlock (system hang) with a concrete trigger and stack
  trace
- Extremely small and contained fix (3 lines in 1 function in 1 file)
- Uses the standard, well-established `memalloc_noio_save/restore`
  kernel API
- Reviewed by erofs maintainer (Gao Xiang) and key reviewer (Chao Yu)
- Committed through the maintainer's fixes tree
- Affects widely-deployed platform configuration (Android + dm-verity +
  erofs)
- Bug has existed since v5.13 and is present in all active stable trees
  v5.15+
- Multiple `GFP_KERNEL` allocation sites confirmed in the decompression
  path (vm_map_ram, kvcalloc)
- Primary read path for compressed erofs — not an obscure corner case
- Pattern of earlier bugs in same optimization area (648f2de,
  12d0a24afd9ea, c99fab6e80b76) demonstrates the area is correctness-
  sensitive
- No existing `memalloc_noio` protection in erofs anywhere

**AGAINST backporting:**
- No explicit `Fixes:` tag or `Cc: stable` (expected for commits needing
  manual review)
- Minor context differences across stable tree versions (trivially
  resolvable)
- NOIO scope affects the entire decompression call, not just
  `vm_map_ram()` (intentional and beneficial — there are multiple
  GFP_KERNEL sites)

**UNRESOLVED:**
- Exact frequency of this deadlock in production (but the trigger
  conditions are realistic)
- Exact lore.kernel.org discussion thread for this specific patch (anti-
  bot protections)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — standard kernel pattern,
   reviewed by maintainer
2. **Fixes a real bug?** YES — deadlock under memory pressure
3. **Important issue?** YES — system hang/deadlock, CRITICAL severity
4. **Small and contained?** YES — 3 lines in 1 file, 1 function
5. **No new features or APIs?** YES — no new features
6. **Can apply to stable?** YES — applicable to v5.15+ with minor
   context adjustment; `memalloc_noio_*` helpers available in all target
   trees

### Step 9.3: Exception Categories
Not applicable (this is a straightforward critical bug fix).

### Step 9.4: Decision
This is a clear, surgical fix for a critical deadlock in the primary
read path of a widely-deployed filesystem. The fix is minimal, uses a
standard kernel API, was reviewed by the subsystem maintainer, and has
virtually no regression risk. It meets all stable kernel criteria.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Gao Xiang (erofs maintainer) and
  Chao Yu. No Fixes: tag (expected). Signed-off-by Jiucheng Xu (Amlogic
  author).
- [Phase 2] Diff analysis: 3 lines added in
  `z_erofs_decompress_kickoff()`, wrapping
  `z_erofs_decompressqueue_work()` with `memalloc_noio_save/restore`.
- [Phase 2] Verified `vm_map_ram()` uses `GFP_KERNEL` at
  `mm/vmalloc.c:3070` (`vb_alloc(size, GFP_KERNEL)`) and line 3078
  (`alloc_vmap_area(..., GFP_KERNEL, ...)`).
- [Phase 2] Verified additional `GFP_KERNEL` allocations in
  decompression: `kvcalloc(..., GFP_KERNEL | __GFP_NOFAIL)` at
  `zdata.c:1300,1304` and `kmalloc(..., GFP_KERNEL | __GFP_NOFAIL)` at
  `zdata.c:1161`.
- [Phase 2] Verified `erofs_vm_map_ram()` at `internal.h:439-452` calls
  `vm_map_ram()`.
- [Phase 3] git blame: Lines 1458-1494 traced to `7865827c432bf9` (Gao
  Xiang, 2022-01-21, rearrangement) and original logic from
  `648f2de053a88` (Huang Jianan, 2021-03-17).
- [Phase 3] `git tag --contains 648f2de053a88`: First appeared in v5.13.
- [Phase 3] `git merge-base --is-ancestor 648f2de053a88 v5.10`: NOT
  ancestor (path absent in v5.10).
- [Phase 3] `git merge-base --is-ancestor 648f2de053a88 v5.15`: IS
  ancestor (path present).
- [Phase 3] `git merge-base --is-ancestor 648f2de053a88 v6.1`: IS
  ancestor.
- [Phase 3] `git merge-base --is-ancestor 648f2de053a88 v6.6`: IS
  ancestor.
- [Phase 3] Related atomic-context fixes verified: `12d0a24afd9ea` (1
  file, 1 line), `c99fab6e80b76` (1 file, 11 lines).
- [Phase 3] `git log --grep='memalloc_noio' -- fs/erofs`: empty — no
  prior NOIO fix in erofs.
- [Phase 3] `git log --author='Jiucheng Xu' -- fs/erofs`: no prior erofs
  commits from author.
- [Phase 4] lore.kernel.org not directly fetchable (anti-bot). Related
  discussion for 12d0a24afd9ea confirms dm-verity + erofs scenario with
  real stack traces.
- [Phase 5] Callers verified: `z_erofs_decompress_kickoff()` called from
  `z_erofs_endio()` (line 1668) and `z_erofs_submit_queue()` (line
  1805).
- [Phase 5] Reachability verified: `z_erofs_read_folio()` (line 1887)
  and `z_erofs_readahead()` (line 1910) are the address_space_operations
  (line 1944-1945).
- [Phase 5] No existing `memalloc_noio_save` in `fs/erofs/` (grep
  confirmed 0 matches).
- [Phase 6] Direct-call path verified in: v5.15 (line 802), v6.1 (line
  1195), v6.6 (line 1435), v6.12 (line 1373).
- [Phase 6] `memalloc_noio_save` helpers exist in
  `include/linux/sched/mm.h` (4 occurrences confirmed).
- [Phase 8] Failure mode: System deadlock/hang in `submit_bio_wait` due
  to bio queued to active `bio_list`, severity CRITICAL.
- UNVERIFIED: Exact lore.kernel.org thread for this specific patch
  (anti-bot protection blocked access).
- UNVERIFIED: Exact real-world frequency of this deadlock in production
  (trigger conditions are realistic based on Android + dm-verity +
  memory pressure).

**YES**

 fs/erofs/zdata.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
index b71fcf4be484a..8ba409df1ca70 100644
--- a/fs/erofs/zdata.c
+++ b/fs/erofs/zdata.c
@@ -1459,6 +1459,7 @@ static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
 				       int bios)
 {
 	struct erofs_sb_info *const sbi = EROFS_SB(io->sb);
+	int gfp_flag;
 
 	/* wake up the caller thread for sync decompression */
 	if (io->sync) {
@@ -1491,7 +1492,9 @@ static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
 			sbi->opt.sync_decompress = EROFS_SYNC_DECOMPRESS_FORCE_ON;
 		return;
 	}
+	gfp_flag = memalloc_noio_save();
 	z_erofs_decompressqueue_work(&io->u.work);
+	memalloc_noio_restore(gfp_flag);
 }
 
 static void z_erofs_fill_bio_vec(struct bio_vec *bvec,
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] platform/x86: hp-wmi: Add support for Omen 16-wf1xxx (8C76)

[Sasha Levin]

From: Krishna Chomal <krishna.chomal108@gmail.com>

[ Upstream commit 84d29bfd1929d08f092851162a3d055a2134d043 ]

The HP Omen 16-wf1xxx (board ID: 8C76) has the same WMI interface as
other Victus S boards, but requires quirks for correctly switching
thermal profile (similar to board 8C78).

Add the DMI board name to victus_s_thermal_profile_boards[] table and
map it to omen_v1_thermal_params.

Testing on board 8C76 confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.

Tested-by: WJ Enderlava <jie7172585@gmail.com>
Reported-by: WJ Enderlava <jie7172585@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221149
Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
Link: https://patch.msgid.link/20260227154106.226809-1-krishna.chomal108@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the data needed for the comprehensive analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [platform/x86: hp-wmi] [Add] [DMI board name 8C76 to Victus S
thermal profile table, mapped to omen_v1_thermal_params]

**Step 1.2: Tags**
Record:
- `Tested-by: WJ Enderlava <jie7172585@gmail.com>` — real user tested on
  hardware
- `Reported-by: WJ Enderlava <jie7172585@gmail.com>` — single reporter,
  real hardware user
- `Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221149` — user-
  filed bugzilla
- `Signed-off-by: Krishna Chomal` — author
- `Link: https://patch.msgid.link/20260227154106.226809-1-
  krishna.chomal108@gmail.com`
- `Reviewed-by: Ilpo Järvinen` — subsystem maintainer reviewed
- `Signed-off-by: Ilpo Järvinen` — maintainer committed
- No `Fixes:` tag (expected for manual review candidates)
- No `Cc: stable` (expected)
- No syzbot involvement

**Step 1.3: Body Text**
Record: Bug: Board 8C76 (HP Omen 16-wf1xxx) has the same WMI interface
as Victus S boards but requires quirks for correct thermal profile
switching (similar to 8C78). Symptom: without the entry, the board
cannot register the platform profile and fan RPMs are not
readable/controllable. Testing confirmed on real hardware that profile
registers and fans work after the fix. Root cause: missing DMI board
name in the quirk table.

**Step 1.4: Hidden Bug Fix Detection**
Record: Yes — phrased as "Add support" but this is a hardware-specific
DMI quirk. Without this entry, the board does not get routed into the
correct thermal handling path, meaning no platform profile registration
and no fan control. This is functionally a bug fix for users of this
specific hardware.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file changed: `drivers/platform/x86/hp/hp-wmi.c`, +4 lines, 0
removed. Single table entry added to
`victus_s_thermal_profile_boards[]`. Scope: single-file, surgical, data-
only change.

**Step 2.2: Code Flow Change**
Record: Before: board "8C76" is not in
`victus_s_thermal_profile_boards[]`, so `dmi_first_match()` in
`setup_active_thermal_profile_params()` does not match it;
`is_victus_s_board` stays false; thermal profile, fan, and power-source
handling all skip the Victus S path. After: "8C76" matches,
`driver_data` = `&omen_v1_thermal_params` (same as "8C78"), enabling the
full Victus S / Omen v1 code path.

**Step 2.3: Bug Mechanism**
Record: Category: Hardware workaround / DMI match table entry. Specific
mechanism: missing board name in DMI quirk table causes incorrect
thermal profile handling for this laptop SKU.

**Step 2.4: Fix Quality**
Record: Obviously correct — identical pattern to adjacent "8C78" entry.
Minimal and surgical (4 lines). Zero regression risk: only activates on
exact DMI board name "8C76". No API or ABI changes.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: `git blame -L 162,191` shows the entire
`victus_s_thermal_profile_boards[]` table (in its `dmi_system_id` form
with `driver_data`) was created by commit `e7cbd37292653` ("fix platform
profile values for Omen 16-wf1xxx", Krishna Chomal, 2026-01-13). The
table structure/`};` terminator originates from `6e4ab59b8391a` (Julien
Robin, 2025-01-16, original Victus S support).

**Step 3.2: Fixes: tag**
Record: N/A — no Fixes: tag present (expected for manual review). The
related prerequisite `e7cbd37292653` itself has `Fixes: fb146a38cb119`.

**Step 3.3: File History**
Record: Recent `hp-wmi.c` history shows: `e7cbd37292653` (per-board
thermal params refactor), `68779adbabdbb` (DMI ordering),
`fa0498f804753` (Omen MAX 16-ah0xx), `fb146a38cb119` (Omen 16-wf1xxx fan
support), `54afb047cd7eb` (Victus 16-r/s). This is a standalone single-
patch addition, not part of a numbered series.

**Step 3.4: Author**
Record: Krishna Chomal has 2 prior commits in
`drivers/platform/x86/hp/`: `fb146a38cb119` (Add Omen 16-wf1xxx fan
support) and `e7cbd37292653` (fix platform profile values for Omen
16-wf1xxx). Author is the original contributor for this specific
hardware support. Reviewed and committed by subsystem maintainer Ilpo
Järvinen.

**Step 3.5: Dependencies**
Record: This patch requires the `dmi_system_id` table format with
`driver_data` pointing to `struct thermal_profile_params`, introduced by
`e7cbd37292653`. It also requires `omen_v1_thermal_params` to be defined
(also from `e7cbd37292653`). Verified: `e7cbd37292653` is contained in
`v6.19.4~320`; `fb146a38cb119` is contained in `v6.18-rc7~24^2~18`.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1–4.4:**
Record: WebFetch attempts to lore.kernel.org, patch.msgid.link, and
bugzilla.kernel.org were blocked by Anubis bot protection. Could not
independently verify the mailing list discussion or bugzilla details.
The commit tags (Reported-by, Tested-by, Reviewed-by, Closes:) provide
the evidence trail. UNVERIFIED: exact bugzilla content and mailing list
discussion.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions in Diff**
Record: No function bodies modified. Data change only: one entry added
to `victus_s_thermal_profile_boards[]`.

**Step 5.2: Callers**
Record: Verified via grep: `victus_s_thermal_profile_boards` is consumed
by `setup_active_thermal_profile_params()` (line 2288), which calls
`dmi_first_match()` on this table. On match, it sets `is_victus_s_board
= true` and `active_thermal_profile_params = id->driver_data`.

**Step 5.3: Callees / Impact Surface**
Record: `is_victus_s_thermal_profile()` (line 1634) returns
`is_victus_s_board`. This function gates behavior in:
- `hp_wmi_platform_profile_probe()` — platform profile registration
  (line 1809, 2009)
- `hp_wmi_hwmon_is_visible()` — fan sysfs visibility (line 2169)
- `hp_wmi_hwmon_read()` — fan speed reading (line 2191)
- `hp_wmi_hwmon_write()` — fan speed control (lines 2227, 2233)
- `hp_wmi_init()` — power source event handler registration (line 2341)
- `hp_wmi_exit()` — cleanup (line 2364)

**Step 5.4: Reachability**
Record: Init path: `hp_wmi_init()` →
`setup_active_thermal_profile_params()` → `platform_driver_probe()` →
`hp_wmi_bios_setup()` → `thermal_profile_setup()`. This runs on every
boot/module load on affected hardware. Hwmon paths are userspace-
reachable via sysfs.

**Step 5.5: Similar Patterns**
Record: The table already contains identical patterns: "8C78" →
`&omen_v1_thermal_params`, "8BCA" → `&omen_v1_thermal_params`, "8BCD" →
`&omen_v1_thermal_params`. This is a routine board-ID addition.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code Existence in Stable Trees**
Record: Verified via `git grep`:
- **pending-6.6, pending-6.12, pending-6.14**:
  `victus_s_thermal_profile_boards` NOT found. Not applicable.
- **pending-6.17**: Table exists (3 references) but uses the OLD string-
  list format. `omen_v1_thermal_params` and `struct
  thermal_profile_params` do NOT exist. Patch cannot apply.
- **pending-6.18**: Table exists in NEW `dmi_system_id` format.
  `omen_v1_thermal_params` exists. "8C76" NOT yet present. Patch applies
  cleanly.
- **pending-6.19**: Table exists in NEW `dmi_system_id` format.
  `omen_v1_thermal_params` exists. "8C76" NOT yet present. Patch applies
  cleanly.

**Step 6.2: Backport Complications**
Record: Clean apply for `6.18.y` and `6.19.y`. Not standalone for
`6.17.y` (would need the full `e7cbd37292653` refactor first). Not
applicable to `6.14.y` and older.

**Step 6.3: Related Fixes Already in Stable**
Record: No alternate "8C76" fix found in any checked branch.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
Record: `drivers/platform/x86/hp/` — HP laptop WMI driver. Criticality:
PERIPHERAL (specific HP laptop hardware). However, HP Omen/Victus is a
popular consumer laptop line.

**Step 7.2: Activity**
Record: Actively maintained — 20 recent commits show ongoing thermal/fan
work for various HP laptop models.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Record: Platform-specific: users of HP Omen 16-wf1xxx laptops with DMI
board name "8C76".

**Step 8.2: Trigger Conditions**
Record: Triggered every boot on affected hardware. DMI matching is init-
time, and the resulting behavior affects all platform-profile and fan-
control operations for the life of the session.

**Step 8.3: Failure Mode Severity**
Record: Without the fix: no platform profile registration, fan RPMs not
readable/controllable via the Victus S path, and power-source event
handling not set up for this board. Severity: MEDIUM — hardware
functionality (thermal management, fan control) is missing but no crash,
corruption, or security issue.

**Step 8.4: Risk-Benefit Ratio**
Record: Benefit: HIGH for affected users — restores correct thermal
profile switching and fan control on their laptop. Risk: VERY LOW —
4-line data-only change scoped to a single DMI board name match, cannot
affect any other hardware. Ratio: strongly favorable.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
FOR backporting:
- Classic hardware quirk / DMI board ID addition (explicit stable
  exception category)
- Only 4 lines, data-only change, zero regression risk
- Reported-by and Tested-by from real user on real hardware
- Reviewed-by subsystem maintainer (Ilpo Järvinen)
- Bugzilla bug report (221149) filed
- Identical pattern to existing adjacent entries (8C78, 8BCA, 8BCD)
- Prerequisites already present in pending-6.18 and pending-6.19

AGAINST backporting:
- Not a crash/security/corruption fix — hardware enablement for missing
  fan/thermal control
- Narrow impact (single laptop model)
- Only applicable to 6.18.y and 6.19.y; 6.17.y needs prerequisite
  refactor

UNRESOLVED:
- Bugzilla 221149 content not fetchable (Anubis blocked)
- Lore mailing list discussion not fetchable (Anubis blocked)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — identical pattern to existing
   entries, Tested-by from hardware owner
2. Fixes a real bug? **YES** — missing quirk prevents thermal/fan
   control on real hardware
3. Important issue? **YES** under the hardware quirk exception — enables
   hardware functionality
4. Small and contained? **YES** — 4 lines, single table entry, one file
5. No new features or APIs? **YES** — extends existing quirk table with
   a board name
6. Can apply to stable? **YES** — cleanly on 6.18.y and 6.19.y

**Step 9.3: Exception Categories**
Record: This falls squarely into **QUIRKS and WORKAROUNDS** — a DMI
board name addition to an existing driver's quirk table. This is the
same category as USB quirks, PCI quirks, and audio codec quirks that are
explicitly allowed in stable.

**Step 9.4: Decision**
This is a textbook hardware quirk addition: a 4-line DMI table entry
that enables correct thermal profile switching and fan control for a
specific HP laptop model, using existing driver infrastructure. It
carries essentially zero regression risk and provides concrete benefit
to real users of this hardware. It should be backported to stable
branches that have the per-board thermal parameter infrastructure
(6.18.y and 6.19.y).

---

## Verification

- [Phase 1] Parsed all tags from commit message: Tested-by, Reported-by,
  Closes (bugzilla 221149), Reviewed-by (Ilpo Järvinen), Link, Signed-
  off-by x2
- [Phase 2] Diff analysis: +4 lines adding single DMI entry `{
  DMI_MATCH(DMI_BOARD_NAME, "8C76"), .driver_data = (void
  *)&omen_v1_thermal_params }`
- [Phase 3] `git blame -L 162,191`: confirmed table created by
  `e7cbd37292653` (Krishna Chomal, 2026-01-13), structure from
  `6e4ab59b8391a` (2025-01-16)
- [Phase 3] `git show e7cbd37292653`: confirmed this is the prerequisite
  commit that refactored the table to `dmi_system_id` format with per-
  board `thermal_profile_params`
- [Phase 3] `git describe --contains e7cbd37292653` → `v6.19.4~320`:
  prerequisite is in v6.19.4
- [Phase 3] `git describe --contains fb146a38cb119` →
  `v6.18-rc7~24^2~18`: original Omen 16-wf1xxx support is in v6.18
- [Phase 3] `git log --author="Krishna Chomal"`: confirmed 2 prior
  commits to hp-wmi.c
- [Phase 4] WebFetch to lore/bugzilla blocked by Anubis — UNVERIFIED:
  exact discussion and bug details
- [Phase 5] `grep` for `victus_s_thermal_profile_boards`: confirmed
  consumed by `setup_active_thermal_profile_params()` at line 2288 via
  `dmi_first_match()`
- [Phase 5] `grep` for `is_victus_s_thermal_profile`: confirmed it gates
  platform profile (lines 1809, 2009), hwmon visibility/read/write
  (lines 2169, 2191, 2227, 2233), init power source handler (line 2341),
  exit cleanup (line 2364)
- [Phase 6] `git grep victus_s_thermal_profile_boards` on all pending
  branches: NOT in 6.6/6.12/6.14; present in 6.17/6.18/6.19
- [Phase 6] `git grep omen_v1_thermal_params` on pending-6.17: NOT FOUND
  — old string-list format, patch cannot apply standalone
- [Phase 6] `git grep omen_v1_thermal_params` on pending-6.18: FOUND
  (lines 92-114, 159, 167, 179) — full infrastructure present
- [Phase 6] `git grep omen_v1_thermal_params` on pending-6.19: FOUND
  (lines 92-114, 167, 175, 187) — full infrastructure present
- [Phase 6] `git grep '8C76'` on pending-6.18 and pending-6.19: NOT
  FOUND — patch not yet applied to any stable branch
- [Phase 8] Failure mode: missing thermal profile/fan control on
  specific HP Omen laptop; severity MEDIUM (hardware functionality, not
  crash/security)
- UNVERIFIED: exact bugzilla 221149 content and severity rating
- UNVERIFIED: exact mailing list reviewer comments beyond tags in commit

**YES**

 drivers/platform/x86/hp/hp-wmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
index 24d065ddfc6ae..9c1bdf8e7b283 100644
--- a/drivers/platform/x86/hp/hp-wmi.c
+++ b/drivers/platform/x86/hp/hp-wmi.c
@@ -172,6 +172,10 @@ static const struct dmi_system_id victus_s_thermal_profile_boards[] __initconst
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BD5") },
 		.driver_data = (void *)&victus_s_thermal_params,
 	},
+	{
+		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8C76") },
+		.driver_data = (void *)&omen_v1_thermal_params,
+	},
 	{
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8C78") },
 		.driver_data = (void *)&omen_v1_thermal_params,
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] ALSA:usb:qcom: add AUXILIARY_BUS to Kconfig dependencies

[Sasha Levin]

From: Frank Zhang <rmxpzlb@gmail.com>

[ Upstream commit b8bee48e38f2ddbdba5e58bc54ef54bb7d8d341b ]

The build can fail with:

ERROR: modpost: "__auxiliary_driver_register"
[sound/usb/qcom/snd-usb-audio-qmi.ko] undefined!
ERROR: modpost: "auxiliary_driver_unregister"
[sound/usb/qcom/snd-usb-audio-qmi.ko] undefined!

Select AUXILIARY_BUS when SND_USB_AUDIO_QMI is enabled.

Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>
Link: https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the technical verification I need. Let me produce the
final answer.

---

## Phase 1: Commit Message Forensics

**Step 1.1: Subject Line**
Record: [ALSA:usb:qcom] [add] [Add missing AUXILIARY_BUS Kconfig
dependency to fix modpost build failure]

**Step 1.2: Tags**
- `Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>` — patch author
- `Link:
  https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com` —
  patch submission
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>` — ALSA subsystem
  maintainer accepted the patch
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable` (expected for candidates under manual review)

Record: Accepted by subsystem maintainer Takashi Iwai. Standalone patch
(not part of a series).

**Step 1.3: Commit Body**
Record: Bug: Enabling `SND_USB_AUDIO_QMI` without `AUXILIARY_BUS` causes
modpost failures: `__auxiliary_driver_register` and
`auxiliary_driver_unregister` are undefined in `snd-usb-audio-qmi.ko`.
Symptom: hard build failure. Root cause: the Kconfig entry for
`SND_USB_AUDIO_QMI` omits the required `select AUXILIARY_BUS`.

**Step 1.4: Hidden Bug Fix?**
Record: Not really hidden — the commit message explicitly describes a
build failure. The word "add" in the subject could be misleading, but
the body makes the bug fix intent clear.

---

## Phase 2: Diff Analysis

**Step 2.1: Inventory**
Record: 1 file changed (`sound/usb/Kconfig`), +1 line added (`select
AUXILIARY_BUS`), 0 lines removed. No functions modified (Kconfig only).
Scope: single-line surgical build fix.

**Step 2.2: Code Flow Change**
Record: Before: `SND_USB_AUDIO_QMI` could be enabled without
`CONFIG_AUXILIARY_BUS`, causing the auxiliary bus object files not to be
compiled, leaving
`__auxiliary_driver_register`/`auxiliary_driver_unregister` unresolved
at link time. After: enabling `SND_USB_AUDIO_QMI` forces
`AUXILIARY_BUS=y`, guaranteeing the symbols are available.

**Step 2.3: Bug Mechanism**
Record: Category: build fix / Kconfig dependency bug. The driver's
source (`qc_audio_offload.c` line 1990) uses
`module_auxiliary_driver()`, which expands to
`auxiliary_driver_register`/`auxiliary_driver_unregister` (declared in
`include/linux/auxiliary_bus.h`). These are implemented in
`drivers/base/auxiliary.o`, which is only built when
`CONFIG_AUXILIARY_BUS` is enabled. Without the `select`, the symbols may
not exist.

**Step 2.4: Fix Quality**
Record: Obviously correct — the driver uses auxiliary bus APIs, so it
must depend on the auxiliary bus. Minimal (1 line). Matches the
established tree-wide pattern (50+ other Kconfig entries use `select
AUXILIARY_BUS`). Regression risk: effectively zero — it only ensures a
core infrastructure module is built.

---

## Phase 3: Git History Investigation

**Step 3.1: Blame**
Record: `git blame` confirms the `SND_USB_AUDIO_QMI` block was
introduced in commit `326bbc348298a` ("ALSA: usb-audio: qcom: Introduce
QC USB SND offloading support", Wesley Cheng, 2025-04-09). The `depends
on USB_XHCI_HCD && USB_XHCI_SIDEBAND` line was later added by
`882826f58b2c4` (Arnd Bergmann, 2025-05-21) — another build fix for the
same driver. No `select AUXILIARY_BUS` exists in the current tree.

**Step 3.2: Fixes Tag**
Record: N/A — no `Fixes:` tag. However, the implied fix target is
`326bbc348298a` which introduced the driver without the AUXILIARY_BUS
dependency.

**Step 3.3: File History**
Record: `git log --oneline -20 -- sound/usb/Kconfig` shows the
SND_USB_AUDIO_QMI entry and the prior Kconfig build fix
(`882826f58b2c4`). This is the **second** Kconfig dependency fix for the
same new driver — a pattern consistent with a recently-introduced driver
stabilizing its build dependencies. This patch is standalone; no multi-
patch series dependency.

**Step 3.4: Author**
Record: Frank Zhang has no other commits under `sound/usb/` in this
tree. However, the patch was accepted by Takashi Iwai, the ALSA
subsystem maintainer, providing quality assurance.

**Step 3.5: Dependencies**
Record: No prerequisites needed. The patch is self-contained: it only
requires the `SND_USB_AUDIO_QMI` Kconfig block to already exist in the
tree.

---

## Phase 4: Mailing List and External Research

**Step 4.1–4.4:**
Record: Lore access was blocked by Anubis anti-bot protection. The patch
link
(`https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com`)
and lore search URLs could not be fetched. Reviewer comments, explicit
stable nominations, or NAKs remain unverified. However, the maintainer
sign-off from Takashi Iwai confirms acceptance through the standard
review process.

---

## Phase 5: Code Semantic Analysis

**Step 5.1: Key Functions**
Record: N/A for C functions — this is a Kconfig-only change. The
relevant code reference is
`module_auxiliary_driver(qc_usb_audio_offload_drv)` at
`sound/usb/qcom/qc_audio_offload.c:1990`.

**Step 5.2–5.4: Code Tracing**
Record: Verified the dependency chain:
1. `sound/usb/qcom/qc_audio_offload.c` line 6: `#include
   <linux/auxiliary_bus.h>`
2. `sound/usb/qcom/qc_audio_offload.c` line 1990:
   `module_auxiliary_driver(qc_usb_audio_offload_drv)`
3. `include/linux/auxiliary_bus.h` defines `module_auxiliary_driver()`
   expanding to
   `auxiliary_driver_register`/`auxiliary_driver_unregister`
4. `drivers/base/Kconfig` line 4-5: `config AUXILIARY_BUS` is a
   promptless `bool` (cannot be enabled by the user directly — must be
   selected by a consumer)
5. Without `select AUXILIARY_BUS`, if no other enabled config selects
   it, the symbols are unavailable → modpost failure

**Step 5.5: Similar Patterns**
Record: `select AUXILIARY_BUS` appears in 50+ Kconfig files across the
tree (drivers/gpu, drivers/net, drivers/clk, drivers/reset, sound/soc,
etc.). This is the standard established pattern for auxiliary bus
consumers. The fix is entirely consistent with tree-wide convention.

---

## Phase 6: Stable Tree Analysis

**Step 6.1: Does the buggy code exist in stable trees?**
Record: Verified via `git show <tag>:sound/usb/Kconfig`:
- `v6.6` — `SND_USB_AUDIO_QMI` does NOT exist (grep returns 0 matches)
- `v6.12` — does NOT exist (0 matches)
- `v6.16` — EXISTS, missing `select AUXILIARY_BUS` (confirmed)
- `v6.19` — EXISTS, missing `select AUXILIARY_BUS` (confirmed)

The introducing commit `326bbc348298a` first appears in `v6.16` and all
subsequent releases. Older LTS branches (6.6.y, 6.12.y, 6.1.y) are
unaffected — the driver does not exist there.

**Step 6.2: Backport complications**
Record: Clean apply expected. The `SND_USB_AUDIO_QMI` Kconfig block is
materially identical across affected tags. One-line insertion should
apply without conflicts.

**Step 6.3: Related fixes in stable**
Record: No `AUXILIARY_BUS` fix found in any of the affected stable tags.
The prior related build fix (`882826f58b2c4` for USB_XHCI_HCD) is
already present in v6.19 but addresses a different missing dependency.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1: Subsystem**
Record: `sound/usb` — ALSA USB audio, Qualcomm offload driver.
Criticality: PERIPHERAL (hardware- and config-specific). However, build
fixes are explicitly listed as stable-appropriate regardless of
subsystem criticality.

**Step 7.2: Activity**
Record: Active development — multiple follow-up fixes since the driver's
introduction in v6.16, indicating a young subsystem still being
stabilized.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1: Who is affected**
Record: Anyone building a kernel with `CONFIG_SND_USB_AUDIO_QMI` enabled
in a configuration where `AUXILIARY_BUS` is not otherwise selected by
another driver. Primarily Qualcomm SoC users and distributions enabling
this driver.

**Step 8.2: Trigger conditions**
Record: Build-time trigger, not runtime. 100% reproducible when the
Kconfig condition is met. Note: the upstream arm64 defconfig
incidentally enables `AUXILIARY_BUS` through `QCOM_PMIC_GLINK`, which
masks the bug in that specific configuration. However, non-default
configs can easily trigger it.

**Step 8.3: Severity**
Record: Build failure at modpost stage — HIGH for affected
configurations (impossible to build the module). Not a runtime crash,
but prevents kernel builds entirely for this config.

**Step 8.4: Risk-benefit ratio**
Record: BENEFIT: High — fixes a hard build break for a supported in-tree
driver. RISK: Effectively zero — one-line Kconfig `select` addition with
no runtime behavior change, matching an established tree-wide pattern.
Ratio: Very strongly favorable.

---

## Phase 9: Final Synthesis

**Step 9.1: Evidence**
FOR backporting:
- Real build failure (modpost undefined symbols) — documented with exact
  error messages
- Single-line, obviously correct Kconfig fix
- Matches established tree-wide pattern (`select AUXILIARY_BUS` used in
  50+ other Kconfig entries)
- Code path verified: driver uses `module_auxiliary_driver()` → needs
  `AUXILIARY_BUS`
- `AUXILIARY_BUS` is a promptless bool — must be selected, not user-
  enabled
- Zero runtime regression risk
- Accepted by ALSA subsystem maintainer (Takashi Iwai)
- Second build fix for the same driver (pattern of missing deps from
  initial introduction — `882826f58b2c4` was the first)
- Bug confirmed present in all affected stable tags (6.16.y through
  6.19.y)

AGAINST backporting:
- Not relevant to stable trees older than v6.16 (driver does not exist
  there)
- Narrow audience (Qualcomm USB audio offload users)

UNRESOLVED:
- Lore discussion not accessible (Anubis anti-bot)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — driver uses auxiliary bus
   API, must depend on it
2. Fixes a real bug? **YES** — modpost build failure
3. Important issue? **YES** — prevents compilation of a supported driver
4. Small and contained? **YES** — 1 line, 1 file
5. No new features or APIs? **YES** — only adds missing build dependency
6. Can apply to stable? **YES** — clean apply on v6.16+ branches

**Step 9.3: Exception Categories**
Record: **Build fix** — explicitly listed as an exception category that
is automatically YES for stable.

**Step 9.4: Decision**
This is a textbook build fix: a single-line Kconfig `select` addition
that fixes a real modpost link failure for a supported in-tree driver.
It should be backported to stable trees that contain `SND_USB_AUDIO_QMI`
(v6.16.y and newer). It is not applicable to older LTS branches
(v6.12.y, v6.6.y, v6.1.y) where the driver does not exist.

---

## Verification

- [Phase 1] Parsed commit message and tags directly: `Link:` and two
  `Signed-off-by:` tags present; no `Fixes:`, `Reported-by:`, `Tested-
  by:`, or `Cc: stable`
- [Phase 2] Diff: confirmed single `+     select AUXILIARY_BUS` line
  added under `SND_USB_AUDIO_QMI` in `sound/usb/Kconfig`
- [Phase 3] `git blame -L 191,205 -- sound/usb/Kconfig`: confirmed
  `SND_USB_AUDIO_QMI` introduced by `326bbc348298a` (Wesley Cheng,
  2025-04-09); deps line touched by `882826f58b2c4` (Arnd Bergmann,
  2025-05-21)
- [Phase 3] `git show 882826f58b2c4`: confirmed this was a prior Kconfig
  build fix for the same driver (missing `USB_XHCI_HCD` dependency),
  also with `Fixes: 326bbc348298` tag
- [Phase 3] `git log --oneline -20 -- sound/usb/Kconfig`: confirmed
  recent history, no existing `AUXILIARY_BUS` fix
- [Phase 4] WebFetch to lore/patch.msgid.link: blocked by Anubis anti-
  bot — UNVERIFIED: mailing list discussion details
- [Phase 5] Grep `sound/usb/qcom/`: confirmed `#include
  <linux/auxiliary_bus.h>` at line 6 and
  `module_auxiliary_driver(qc_usb_audio_offload_drv)` at line 1990 of
  `qc_audio_offload.c`
- [Phase 5] Read `drivers/base/Kconfig` lines 4-5: confirmed
  `AUXILIARY_BUS` is a promptless `bool` — must be selected by consumers
- [Phase 5] Grep `select AUXILIARY_BUS` across Kconfig files: confirmed
  50+ other consumers use this pattern
- [Phase 6] `git show v6.6:sound/usb/Kconfig | grep SND_USB_AUDIO_QMI`:
  0 matches — driver does not exist in v6.6
- [Phase 6] `git show v6.12:sound/usb/Kconfig | grep SND_USB_AUDIO_QMI`:
  0 matches — driver does not exist in v6.12
- [Phase 6] `git show v6.16:sound/usb/Kconfig`: confirmed
  `SND_USB_AUDIO_QMI` exists, `select AUXILIARY_BUS` missing
- [Phase 6] `git show v6.19:sound/usb/Kconfig`: confirmed
  `SND_USB_AUDIO_QMI` exists, `select AUXILIARY_BUS` missing
- [Phase 6] `git tag --contains 326bbc348298a`: confirmed first
  appearance at v6.16; present through v6.19.x
- [Phase 8] Failure mode: modpost undefined symbol error — build
  failure, severity HIGH for affected configs
- UNVERIFIED: lore.kernel.org discussion details (anti-bot protection
  blocked access)

**YES**

 sound/usb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
index 9b890abd96d34..b4588915efa11 100644
--- a/sound/usb/Kconfig
+++ b/sound/usb/Kconfig
@@ -192,6 +192,7 @@ config SND_USB_AUDIO_QMI
 	tristate "Qualcomm Audio Offload driver"
 	depends on QCOM_QMI_HELPERS && SND_USB_AUDIO && SND_SOC_USB
 	depends on USB_XHCI_HCD && USB_XHCI_SIDEBAND
+	select AUXILIARY_BUS
 	help
 	  Say Y here to enable the Qualcomm USB audio offloading feature.
 
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.12] drm/amdgpu: Handle GPU page faults correctly on non-4K page systems

[Sasha Levin]

From: Donet Tom <donettom@linux.ibm.com>

[ Upstream commit 4e9597f22a3cb8600c72fc266eaac57981d834c8 ]

During a GPU page fault, the driver restores the SVM range and then maps it
into the GPU page tables. The current implementation passes a GPU-page-size
(4K-based) PFN to svm_range_restore_pages() to restore the range.

SVM ranges are tracked using system-page-size PFNs. On systems where the
system page size is larger than 4K, using GPU-page-size PFNs to restore the
range causes two problems:

Range lookup fails:
Because the restore function receives PFNs in GPU (4K) units, the SVM
range lookup does not find the existing range. This will result in a
duplicate SVM range being created.

VMA lookup failure:
The restore function also tries to locate the VMA for the faulting address.
It converts the GPU-page-size PFN into an address using the system page
size, which results in an incorrect address on non-4K page-size systems.
As a result, the VMA lookup fails with the message: "address 0xxxx VMA is
removed".

This patch passes the system-page-size PFN to svm_range_restore_pages() so
that the SVM range is restored correctly on non-4K page systems.

Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 074fe395fb13247b057f60004c7ebcca9f38ef46)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

All key facts verified. Here is the complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [drm/amdgpu] [Handle correctly] [Fix PFN unit conversion for SVM
range restore on non-4K page systems]

**Step 1.2: Tags**
- Acked-by: Christian König (verified AMDGPU co-maintainer via
  MAINTAINERS)
- Signed-off-by: Donet Tom <donettom@linux.ibm.com> (author, IBM — Power
  systems with 64K pages)
- Signed-off-by: Alex Deucher (verified AMDGPU co-maintainer via
  MAINTAINERS)
- Cherry-picked from: 074fe395fb13247b057f60004c7ebcca9f38ef46 (pipeline
  marker, ignored)
- No Fixes:, Reported-by:, Link:, Cc: stable, Tested-by: tags (expected
  for candidates)

Record: [Acked-by from subsystem co-maintainer; author from IBM; merged
by subsystem co-maintainer. No reporter or explicit stable nomination.]

**Step 1.3: Commit Body**
Two concrete bugs described:
1. **SVM Range lookup failure**: `svm_range_restore_pages()` receives
   PFNs in GPU (4K) units, but the SVM interval tree is indexed by
   system-page PFNs. On non-4K systems, the lookup fails and a
   **duplicate SVM range** is created.
2. **VMA lookup failure**: The restore function does `vma_lookup(mm,
   addr << PAGE_SHIFT)`, which reconstructs the byte address from a
   system-page PFN. When given a GPU-page PFN instead, the computed
   address is wrong, producing `"address 0xxxx VMA is removed"`.

Record: [Bug: wrong PFN unit passed to SVM restore] [Symptoms: duplicate
SVM range + false VMA removal] [Root cause: addr /= AMDGPU_GPU_PAGE_SIZE
gives GPU-page PFN where system-page PFN is expected] [No version info
in message]

**Step 1.4: Hidden Bug Fix Detection**
Record: [Explicit bug fix — "Handle ... correctly" is standard bug-fix
language with concrete failure modes described]

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: [1 file: `amdgpu_vm.c`, ~3 logical lines changed] [Function:
`amdgpu_vm_handle_fault()`] [Scope: single-file, single-function
surgical fix]

**Step 2.2: Code Flow Change**

Before:

```2976:2982:drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
        addr /= AMDGPU_GPU_PAGE_SIZE;

        if (is_compute_context && !svm_range_restore_pages(adev, pasid,
vmid,
            node_id, addr, ts, write_fault)) {
                amdgpu_bo_unref(&root);
                return true;
        }
```

After (from the diff): `addr >> PAGE_SHIFT` is passed to
`svm_range_restore_pages()`, and `addr /= AMDGPU_GPU_PAGE_SIZE` is moved
to after the SVM call for the GPU page-table update path.

Record: [Before: one conversion (GPU-page PFN) was reused for both SVM
restore and GPU PTE update. After: SVM restore gets system-page PFN; GPU
PTE path still gets GPU-page PFN.]

**Step 2.3: Bug Mechanism**
Category: Logic/correctness — address unit mismatch.

Verified from `kfd_svm.c`:
- `svm_range_from_addr()` documentation says `@addr: address to search
  range interval tree, in pages` (system pages)
- `vma_lookup(mm, addr << PAGE_SHIFT)` at line 3136 converts back to
  byte address using system page shift

`AMDGPU_GPU_PAGE_SIZE` is confirmed as `4096` in `amdgpu_gart.h:35`.

On 4K systems: `addr >> PAGE_SHIFT == addr / 4096` — identical, bug
invisible.
On 64K systems: `addr / 4096` gives a value 16x too large compared to
`addr >> 16`.

Record: [Logic/correctness bug. GPU-page PFN vs system-page PFN mismatch
breaks SVM range and VMA lookups on non-4K systems.]

**Step 2.4: Fix Quality**
Record: [Obviously correct — callee contract verified in code. Minimal —
~3 lines. No regression risk on 4K systems (mathematically identical).
Very low risk overall.]

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Verified via `git blame`: The buggy `addr /= AMDGPU_GPU_PAGE_SIZE`
before the SVM call was introduced by `ea53af8a59c89b` ("drm/amdkfd: SVM
API call to restore page tables") by Alex Sierra (2020-05-11). First
appeared in `v5.14-rc1`.

Record: [Buggy code introduced in ea53af8a59c89b, first in v5.14-rc1.
Present in all stable trees 5.15+.]

**Step 3.2: Fixes Tag**
Record: [No Fixes: tag — expected for candidates under review.]

**Step 3.3: File History**
Verified via `git log -20`: Recent `amdgpu_vm.c` changes are TLB/VM
maintenance and unrelated. No conflicting fix for this PFN issue exists.

Record: [No related prior fix found. Standalone change.]

**Step 3.4: Author**
Donet Tom (IBM) has 2 AMD-tree commits in local history, including
`daea2e81c1804` ("drm/amdkfd: Fix GART PTE for non-4K pagesize in
svm_migrate_gart_map()") — a closely related non-4K fix. Acked by
Christian König and merged by Alex Deucher, both confirmed as listed
AMDGPU maintainers in `MAINTAINERS`.

Record: [Author is domain expert for non-4K page issues. Fix endorsed by
both subsystem maintainers.]

**Step 3.5: Dependencies**
Record: [No dependencies. Only reorders unit conversions within one
function. Standalone fix.]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.4**: Lore.kernel.org was inaccessible due to Anubis bot
protection. The commit has strong maintainer endorsement (Acked-by +
Signed-off-by from both AMDGPU co-maintainers). The related patch series
context (non-4K page support for AMDGPU on Power10/MI210 platforms) is
documented in public archives.

Record: [Lore inaccessible. Maintainer ack and signoff confirmed from
tags. UNVERIFIED: detailed reply-thread discussion on lore.]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
Record: [`amdgpu_vm_handle_fault()`]

**Step 5.2: Callers**
Verified callers in: `gmc_v9_0.c`, `gmc_v10_0.c`, `gmc_v11_0.c`,
`gmc_v12_0.c` — GPU page fault interrupt handlers for all AMD GPU
generations 9+.

Confirmed in `gmc_v10_0.c:114`: `addr = (u64)entry->src_data[0] << 12` —
the fault address is constructed as a **byte address** from hardware
interrupt data.

Record: [Called from GPU page fault interrupt handlers. addr is byte
address from hardware.]

**Step 5.3: Callees**
`svm_range_restore_pages()` (verified at `kfd_svm.c:3000`) calls:
- `svm_range_from_addr()` — interval tree lookup using system-page PFN
- `vma_lookup(mm, addr << PAGE_SHIFT)` at line 3136 — reconstructs byte
  address from system-page PFN

Record: [Both callees confirmed to expect system-page PFNs.]

**Step 5.4: Call Chain**
GPU fault interrupt → `gmc_v*_process_interrupt()` →
`amdgpu_vm_handle_fault()` → `svm_range_restore_pages()`. Triggered by
any GPU memory access fault in compute contexts (ROCm/HSA workloads).

Record: [Reachable from normal GPU compute workloads. Not theoretical —
triggered by SVM retry faults.]

**Step 5.5: Similar Patterns**
Record: [Related non-4K fix exists: `daea2e81c1804` by the same author.
No duplicate of this exact wrong-unit call found.]

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Bug Existence in Stable Trees**
Verified the identical bug pattern (`addr /= AMDGPU_GPU_PAGE_SIZE`
before `svm_range_restore_pages()`) exists in:
- **v5.15**: line 3376 (`svm_range_restore_pages(adev, pasid, addr,
  write_fault)`)
- **v6.1**: line 2476 (same pattern, 4-param signature)
- **v6.6**: line 2574 (`svm_range_restore_pages(adev, pasid, vmid,
  node_id, addr, write_fault)`)

Record: [Bug confirmed in v5.15, v6.1, v6.6 stable trees. All share the
same `addr /= AMDGPU_GPU_PAGE_SIZE` before SVM call.]

**Step 6.2: Backport Complications**
Function signatures differ across versions:
- v5.15/v6.1: `svm_range_restore_pages(adev, pasid, addr, write_fault)`
  — 4 params
- v6.6: `svm_range_restore_pages(adev, pasid, vmid, node_id, addr,
  write_fault)` — 6 params
- v6.12+: `svm_range_restore_pages(adev, pasid, vmid, node_id, addr, ts,
  write_fault)` — 7 params

The core fix (move `addr /= AMDGPU_GPU_PAGE_SIZE` after SVM call, pass
`addr >> PAGE_SHIFT`) applies identically, but the SVM call arguments
differ.

Record: [Clean apply on v6.12+. Minor trivial context adaptation needed
for v6.6 and v5.15/v6.1. Fix concept is identical across all versions.]

**Step 6.3: Related Fixes in Stable**
Record: [No alternative fix for this specific issue found in any stable
tree.]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
Record: [`drivers/gpu/drm/amd/amdgpu` — AMD GPU VM fault handling / KFD
SVM. Criticality: IMPORTANT (common GPU driver, compute/AI workloads)]

**Step 7.2: Activity**
Record: [Highly active subsystem with 20+ recent commits.]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users of AMD GPUs on systems with non-4K page sizes:
- Power (ppc64le) with 64K pages — common in HPC/AI (IBM systems with
  AMD Instinct GPUs)
- ARM64 systems configured with 16K or 64K pages
- Not x86_64 (always 4K pages)

Record: [Platform-specific: Power and ARM64 with non-4K pages using
AMDGPU compute (SVM/XNACK)]

**Step 8.2: Trigger Conditions**
Any GPU page fault during compute (ROCm/KFD) workloads on non-4K page
systems.

Record: [Triggered during normal GPU compute workloads on affected
platforms. Common for those users.]

**Step 8.3: Failure Mode Severity**
- SVM range lookup fails → duplicate range created (memory
  corruption/inconsistency in GPU VM state)
- VMA lookup fails → fault recovery does not happen, workload broken
  with "VMA is removed" error
- This is functional breakage: GPU compute workloads are broken on
  affected platforms

Record: [Severity: HIGH — GPU compute fault recovery is broken on non-4K
page systems, leading to functional failure]

**Step 8.4: Risk-Benefit Ratio**
- **Benefit**: HIGH for affected platforms — fixes completely broken SVM
  fault recovery
- **Risk**: VERY LOW — ~3 lines, no behavior change on 4K systems
  (mathematically identical), obviously correct unit conversion
- **Ratio**: Extremely favorable

Record: [Benefit: HIGH. Risk: VERY LOW. Extremely favorable.]

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backporting:
- Verified wrong-unit bug in code: `svm_range_from_addr` expects system-
  page PFN ("in pages" in documentation), `vma_lookup(mm, addr <<
  PAGE_SHIFT)` expects system-page PFN
- Callers pass byte addresses from hardware; fix correctly separates
  system-page and GPU-page conversions
- Small, surgical fix (~3 lines in 1 file, 1 function)
- On 4K systems behavior is mathematically identical (no regression
  risk)
- Acked by Christian König, merged by Alex Deucher (both verified AMDGPU
  maintainers)
- Bug introduced in v5.14-rc1, confirmed present in v5.15, v6.1, v6.6
- Related non-4K fix by same author already in tree
- No dependencies; standalone fix

AGAINST backporting:
- Affects only non-4K page platforms (niche but real user base: Power +
  ARM64 with non-4K pages)
- Minor signature adaptation needed for older stable trees
- No Reported-by or syzbot report (expected; this is platform-specific,
  not fuzzable)

UNRESOLVED:
- Could not access lore.kernel.org discussion threads

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — verified by code inspection;
   Acked by subsystem maintainer
2. Fixes a real bug? **YES** — SVM fault recovery broken on non-4K
   systems
3. Important issue? **YES** — functional failure (GPU compute broken) on
   affected platforms
4. Small and contained? **YES** — ~3 lines in 1 file
5. No new features or APIs? **YES** — pure correctness fix
6. Can apply to stable? **YES** — with trivial adaptation for older call
   signatures

**Step 9.3: Exception Categories**
Record: [Not applicable — standard bug fix]

**Step 9.4: Decision**
This is a clear, small, obviously correct bug fix that resolves a real
functional failure on non-4K page systems. The fix gives
`svm_range_restore_pages()` a system-page PFN (which it expects) instead
of a GPU-page PFN (which it cannot use correctly on non-4K page
systems). It has no behavior change on the dominant 4K-page x86_64
platforms, and is endorsed by both AMDGPU subsystem maintainers. The bug
exists in all active stable trees from v5.15 onward. This meets all
stable kernel criteria with an extremely favorable risk-benefit ratio.

---

## Verification

- [Phase 1] Parsed tags from supplied commit: Acked-by Christian König,
  SOB Donet Tom (IBM), SOB Alex Deucher
- [Phase 2] Read current `amdgpu_vm.c` lines 2976-2982: confirmed `addr
  /= AMDGPU_GPU_PAGE_SIZE` before `svm_range_restore_pages()` (pre-fix
  code)
- [Phase 2] Read `kfd_svm.c` line 2657: confirmed `svm_range_from_addr`
  documents `@addr` as "in pages" (system pages)
- [Phase 2] Grep on `kfd_svm.c`: confirmed `vma_lookup(mm, addr <<
  PAGE_SHIFT)` at line 3136
- [Phase 2] Grep on `amdgpu_gart.h:35`: confirmed `AMDGPU_GPU_PAGE_SIZE`
  is `4096`
- [Phase 3] `git blame -L 2976,2982`: confirmed buggy conversion
  introduced by `ea53af8a59c89b` (Alex Sierra, 2020-05-11)
- [Phase 3] `git describe --contains ea53af8a59c89b`: confirmed first in
  `v5.14-rc1`
- [Phase 3] `git log --author='Donet Tom' -- drivers/gpu/drm/amd/`:
  found related `daea2e81c1804` non-4K fix
- [Phase 3] Verified Christian König and Alex Deucher are listed AMDGPU
  maintainers in `MAINTAINERS`
- [Phase 5] Grep confirmed callers in `gmc_v9_0.c`, `gmc_v10_0.c`,
  `gmc_v11_0.c`, `gmc_v12_0.c`
- [Phase 5] Grep on `gmc_v10_0.c:114`: confirmed `addr =
  (u64)entry->src_data[0] << 12` (byte address from HW)
- [Phase 5] Read `kfd_svm.c:3000-3003`: confirmed
  `svm_range_restore_pages()` signature with `uint64_t addr`
- [Phase 6] `git show v5.15:amdgpu_vm.c`: confirmed same `addr /=
  AMDGPU_GPU_PAGE_SIZE` before SVM call at line 3376
- [Phase 6] `git show v6.1:amdgpu_vm.c`: confirmed same bug pattern at
  line 2476
- [Phase 6] `git show v6.6:amdgpu_vm.c`: confirmed same bug pattern at
  lines 2574-2577 (with 6-param signature)
- [Phase 6] Confirmed function signatures differ: v5.15/v6.1 use 4
  params, v6.6 uses 6 params, mainline uses 7 params
- UNVERIFIED: Could not access lore.kernel.org mailing list discussion
  (Anubis bot protection)

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index da25ba1578b4a..1194326e66f5d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2973,14 +2973,14 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev, u32 pasid,
 	if (!root)
 		return false;
 
-	addr /= AMDGPU_GPU_PAGE_SIZE;
-
 	if (is_compute_context && !svm_range_restore_pages(adev, pasid, vmid,
-	    node_id, addr, ts, write_fault)) {
+	    node_id, addr >> PAGE_SHIFT, ts, write_fault)) {
 		amdgpu_bo_unref(&root);
 		return true;
 	}
 
+	addr /= AMDGPU_GPU_PAGE_SIZE;
+
 	r = amdgpu_bo_reserve(root, true);
 	if (r)
 		goto error_unref;
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.1] ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk

[Sasha Levin]

From: Andrii Kovalchuk <coderpy4@proton.me>

[ Upstream commit 793b008cd39516385791a1d1d223d817e947a471 ]

Add a PCI quirk for HP ENVY Laptop 13-ba0xxx (PCI device ID 0x8756)
to enable proper mute LED and mic mute behavior using the
ALC245_FIXUP_HP_X360_MUTE_LEDS fixup.

Signed-off-by: Andrii Kovalchuk <coderpy4@proton.me>
Link: https://patch.msgid.link/u0s-uRVegF9BN0t-4JnOUwsIAR-mVc4U4FJfJHdEHX7ro_laErHD9y35NebWybcN16gVaVHPJo1ap3AoJ1a2gqJImPvThgeNt_SYVY1KaDw=@proton.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the verified facts I need. Let me compile the final
analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [ALSA: hda/realtek] [Add] [Add HP ENVY Laptop 13-ba0xxx quirk
for mute LED / mic mute behavior]

**Step 1.2: Tags**
Record:
- Signed-off-by: Andrii Kovalchuk `<coderpy4@proton.me>` (author)
- Link: `https://patch.msgid.link/...` (patch submission)
- Signed-off-by: Takashi Iwai `<tiwai@suse.de>` (ALSA subsystem
  maintainer)
- No Fixes: tag (expected for a quirk addition)
- No Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc: stable

**Step 1.3: Commit Body**
Record: Bug: On HP ENVY Laptop 13-ba0xxx (PCI SSID 0x103c:0x8756), the
mute LED and mic-mute LED do not function correctly because the driver
lacks a quirk entry mapping this SSID to the appropriate fixup. Symptom:
incorrect mute LED and mic-mute behavior. Root cause: missing PCI quirk
table entry. No stack traces, crash descriptions, or version ranges
mentioned.

**Step 1.4: Hidden Bug Fix Detection**
Record: Not a hidden bug fix — this is an explicit hardware quirk
addition. It fixes a real user-visible hardware issue (broken LED
indicators) but is presented straightforwardly as a quirk addition.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: `sound/hda/codecs/realtek/alc269.c`: +1 line, -0 lines. Single
`SND_PCI_QUIRK()` entry added to `alc269_fixup_tbl[]`. Scope: single-
file, single-line, table-only surgical addition.

**Step 2.2: Code Flow Change**
Record: Before: PCI SSID 0x103c:0x8756 has no match in
`alc269_fixup_tbl[]`, so `snd_hda_pick_fixup()` does not select any
fixup for this laptop — default generic behavior, LEDs non-functional.
After: SSID matches `ALC245_FIXUP_HP_X360_MUTE_LEDS`, which calls
existing `alc245_fixup_hp_mute_led_coefbit` chained to
`ALC245_FIXUP_HP_GPIO_LED`.

**Step 2.3: Bug Mechanism**
Record: Category: hardware workaround / quirk table entry. Mechanism:
Missing PCI SSID in quirk table prevents selection of already-
implemented fixup for one specific HP laptop model.

**Step 2.4: Fix Quality**
Record: Obviously correct — follows the identical pattern of hundreds of
other entries in the same table. Minimal (1 line). Regression risk is
essentially zero: `snd_hda_pick_fixup()` matches by exact PCI SSID, so
only device 0x103c:0x8756 is affected. No API changes, no locking
changes, no logic changes.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: The neighboring quirk lines in `alc269_fixup_tbl[]` trace to the
July 2025 Realtek driver split (file moved from
`sound/pci/hda/patch_realtek.c` to `sound/hda/codecs/realtek/alc269.c`).
The quirk infrastructure and the fixup `ALC245_FIXUP_HP_X360_MUTE_LEDS`
are long-standing.

**Step 3.2: Fixes: tag**
Record: N/A — no Fixes: tag present, which is expected for a quirk
addition.

**Step 3.3: File History**
Record: `git log --oneline -20 -- sound/hda/codecs/realtek/alc269.c`
shows many similar quirk additions (HP, Samsung, Acer, Lenovo, etc.).
This is the standard maintenance pattern for the Realtek HDA driver.
This commit is standalone — not part of a numbered series.

**Step 3.4: Author**
Record: `git log --author='Andrii Kovalchuk' -10 -- sound/` returned no
results — first-time contributor. However, the patch was accepted and
signed off by Takashi Iwai (ALSA subsystem maintainer), which is a
strong quality signal.

**Step 3.5: Dependencies**
Record: The only prerequisite is that `ALC245_FIXUP_HP_X360_MUTE_LEDS`
must exist in the target tree. Verified:
- **v6.6**: Present (3 occurrences in `sound/pci/hda/patch_realtek.c`) ✓
- **v6.12**: Present (6 occurrences) ✓
- **v6.1**: **NOT present** (0 occurrences) ✗
- **v5.15**: **NOT present** (0 occurrences) ✗

This commit is standalone for v6.6+ trees but **cannot** be backported
to v6.1 or v5.15 without first backporting the prerequisite fixup.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Patch Discussion**
Record: Direct lore.kernel.org and patch.msgid.link fetches were blocked
by anti-bot protection. Via an alternative readable mirror, the thread
shows a standalone [PATCH] submission. Takashi Iwai's only feedback was
about email formatting — no technical objections. He manually corrected
and applied the patch. No reviewer suggested Cc: stable. No NAKs.

**Step 4.2: Bug Report**
Record: No separate public bug report found. No Reported-by: tag. The
patch thread itself serves as the primary evidence of the user-visible
issue.

**Step 4.3: Related Patches**
Record: This is a standalone one-line patch, not part of a series.
Similar quirks exist for other HP ENVY models using the same fixup
(0x876e for 13-ay0xxx, 0x888a for 15-eu0xxx, etc.).

**Step 4.4: Stable Discussion**
Record: No stable-specific discussion found for this commit. However,
analogous HP ENVY quirk additions have historically carried `Cc:
stable@vger.kernel.org`, demonstrating this pattern is routinely
considered for stable.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
Record: No functions modified. Only a static data table entry added to
`alc269_fixup_tbl[]`.

**Step 5.2: Callers**
Record: The quirk table is consumed by `snd_hda_pick_fixup(codec,
alc269_fixup_models, alc269_fixup_tbl, alc269_fixups)` called from
`alc269_probe()` at line 8572-8573 of `alc269.c`. The codec driver
registers `.probe = alc269_probe` via
`module_hda_codec_driver(alc269_driver)`.

**Step 5.3: Callees**
Record: The fixup `ALC245_FIXUP_HP_X360_MUTE_LEDS` (line 6401-6406)
calls `.v.func = alc245_fixup_hp_mute_led_coefbit` and chains to
`ALC245_FIXUP_HP_GPIO_LED`. All existing, well-tested code.

**Step 5.4: Reachability**
Record: Call chain: `module_hda_codec_driver` → `alc269_probe` →
`snd_hda_pick_fixup()` → match PCI SSID against table. Triggered during
codec probe on every boot/module-load on the affected laptop. Real and
reachable.

**Step 5.5: Similar Patterns**
Record: Verified 4 other devices already use this exact fixup in the
same table:
- 0x876e (HP ENVY x360 Convertible 13-ay0xxx)
- 0x888a (HP ENVY x360 Convertible 15-eu0xxx)
- 0x8c21 (HP Pavilion Plus Laptop 14-ey0XXX)
- 0x8cbd (HP Pavilion Aero Laptop 13-bg0xxx)

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code Existence in Stable**
Record: Verified via `git show`:
- **v6.6**: `ALC245_FIXUP_HP_X360_MUTE_LEDS` exists in
  `sound/pci/hda/patch_realtek.c` (3 matches). SSID 0x8756 is NOT
  present — the bug exists here. **Applicable.**
- **v6.12**: Fixup present (6 matches). **Applicable.**
- **v6.1**: Fixup does NOT exist. **Not applicable without
  prerequisite.**
- **v5.15**: Fixup does NOT exist. **Not applicable without
  prerequisite.**

**Step 6.2: Backport Complications**
Record: For v6.6.y: trivial backport — the one-line entry goes into
`sound/pci/hda/patch_realtek.c` (pre-split file path) instead of
`sound/hda/codecs/realtek/alc269.c`. Context lines for the adjacent
entries (0x8736, 0x8760) should be present. Minor context adjustment
needed.

**Step 6.3: Related Fixes Already in Stable**
Record: No existing fix for SSID 0x8756 found in v6.6.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
Record: sound/hda (HDA audio, Realtek codec driver). Criticality:
IMPORTANT — laptop audio is user-facing and widely used, though this
specific fix affects one hardware model.

**Step 7.2: Activity**
Record: Very active subsystem — recent history shows continuous stream
of quirk additions for various laptop models. Mature, well-maintained
driver with established patterns.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Record: Hardware-specific: owners of HP ENVY Laptop 13-ba0xxx (PCI SSID
0x103c:0x8756). This is a consumer laptop — potentially many users.

**Step 8.2: Trigger Conditions**
Record: Every boot. The mute/mic-mute LEDs simply don't work correctly
without this quirk. No special configuration needed.

**Step 8.3: Failure Mode Severity**
Record: MEDIUM — Mute/mic-mute LED indicators don't function correctly.
This is a usability and privacy concern (users can't visually confirm
mic state), but not a crash, data corruption, or security vulnerability.

**Step 8.4: Risk-Benefit Ratio**
Record:
- Benefit: Moderate — fixes broken hardware functionality for real
  laptop users
- Risk: Very low — 1 line, device-specific (only SSID 0x103c:0x8756),
  uses proven fixup used by 4+ other devices
- Ratio: Strongly favorable for backporting

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**

FOR backporting:
- Single-line hardware quirk addition (1 line added)
- Uses existing, well-tested fixup (`ALC245_FIXUP_HP_X360_MUTE_LEDS`)
  already used by 4 other HP devices
- Zero regression risk — only activates on PCI SSID 0x103c:0x8756
- Accepted by ALSA subsystem maintainer Takashi Iwai with no technical
  objections
- Fixes real user-visible hardware issue on a consumer laptop
- Prerequisite fixup verified present in v6.6+
- Falls squarely under the "audio codec quirk" stable exception

AGAINST backporting:
- Not a crash, security issue, or data corruption — "only" a
  usability/hardware fix
- Not applicable to v6.1 or v5.15 without prerequisite backport

UNRESOLVED:
- No independent public bug report found (patch thread is the only
  evidence)
- Did not verify every active stable branch newer than v6.6

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — standard `SND_PCI_QUIRK`
   table entry, maintainer-accepted
2. Fixes a real bug? **YES** — mute/mic-mute LEDs non-functional on this
   hardware
3. Important issue? **YES under quirk exception** — hardware enablement
   for a consumer laptop
4. Small and contained? **YES** — 1 line in 1 file
5. No new features or APIs? **YES** — uses existing fixup mechanism
6. Can apply to stable? **YES** for v6.6+ (with file path adjustment);
   NO for v6.1/v5.15 as standalone

**Step 9.3: Exception Categories**
Record: **Audio codec quirk** (`SND_PCI_QUIRK` entry in Realtek HDA
driver) — explicitly listed as a stable-appropriate exception.

**Step 9.4: Decision**
This is a textbook stable-worthy hardware quirk. One line, zero
regression risk, fixes real hardware for real users, uses an existing
well-tested fixup. Good stable material for branches that already
contain `ALC245_FIXUP_HP_X360_MUTE_LEDS` (v6.6+). Should not be taken as
a standalone patch into older trees (v6.1, v5.15) without the
prerequisite fixup.

---

## Verification

- [Phase 1] Parsed commit message: Add quirk for 0x103c:0x8756 using
  `ALC245_FIXUP_HP_X360_MUTE_LEDS`; tags: SOB ×2, Link
- [Phase 2] Diff: +1 `SND_PCI_QUIRK` line in `alc269_fixup_tbl[]` in
  `sound/hda/codecs/realtek/alc269.c`
- [Phase 3] Verified `ALC245_FIXUP_HP_X360_MUTE_LEDS` definition at
  lines 6401-6406: `.v.func = alc245_fixup_hp_mute_led_coefbit`, chained
  to `ALC245_FIXUP_HP_GPIO_LED`
- [Phase 3] Verified `snd_hda_pick_fixup()` call at lines 8572-8573 in
  `alc269_probe()`
- [Phase 3] Verified 4 other SSIDs use the same fixup: 0x876e, 0x888a,
  0x8c21, 0x8cbd
- [Phase 3] `git log --author='Andrii Kovalchuk'`: no prior commits
  found — first-time contributor
- [Phase 4] Lore/patch.msgid blocked by anti-bot; alternative mirror
  confirmed standalone patch, maintainer feedback was formatting-only,
  no technical objections
- [Phase 5] No functions modified — data-only change
- [Phase 6] `git show v6.6:sound/pci/hda/patch_realtek.c | grep -c
  'ALC245_FIXUP_HP_X360_MUTE_LEDS'`: **3** — fixup present in v6.6
- [Phase 6] `git show v6.12:sound/pci/hda/patch_realtek.c | grep -c
  ...`: **6** — fixup present in v6.12
- [Phase 6] `git show v6.1:sound/pci/hda/patch_realtek.c | grep -c ...`:
  **0** — fixup NOT in v6.1
- [Phase 6] `git show v5.15:sound/pci/hda/patch_realtek.c | grep -c
  ...`: **0** — fixup NOT in v5.15
- [Phase 6] `git show v6.6:... | grep '0x8756'`: empty — SSID not
  already in v6.6, confirming the bug exists there
- [Phase 8] Risk: very low (1 line, SSID-specific). Benefit: fixes
  broken mute LEDs on consumer laptop
- UNVERIFIED: No independent public bug report found for this exact
  laptop model
- UNVERIFIED: Did not inspect every active stable branch newer than v6.6

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 4c49f1195e1bc..39a57d9238497 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6854,6 +6854,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8730, "HP ProBook 445 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8735, "HP ProBook 435 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT),
+	SND_PCI_QUIRK(0x103c, 0x8756, "HP ENVY Laptop 13-ba0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
 	SND_PCI_QUIRK(0x103c, 0x8760, "HP EliteBook 8{4,5}5 G7", ALC285_FIXUP_HP_BEEP_MICMUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x876e, "HP ENVY x360 Convertible 13-ay0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
 	SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED),
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA

[Sasha Levin]

From: Vee Satayamas <vsatayamas@gmail.com>

[ Upstream commit f200b2f9a810c440c6750b56fc647b73337749a1 ]

Add a DMI quirk for the Asus Expertbook BM1403CDA to resolve the issue of the
internal microphone not being detected.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236
Signed-off-by: Vee Satayamas <vsatayamas@gmail.com>
Reviewed-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1:** Record: [ASoC: amd: yc] [Add] DMI quirk for ASUS
EXPERTBOOK BM1403CDA to fix internal microphone not being detected.

**Step 1.2:** Record:
- `Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236` — user-
  filed bug report
- `Signed-off-by: Vee Satayamas <vsatayamas@gmail.com>` — patch author
- `Reviewed-by: Zhang Heng <zhangheng@kylinos.cn>` — peer review
  (notably Zhang Heng authored the sibling PM1503CDA quirk,
  `355aab1aaf77d`)
- `Link:
  https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com`
  — mailing list posting
- `Signed-off-by: Mark Brown <broonie@kernel.org>` — ASoC subsystem
  maintainer merged it
- No `Fixes:` tag, no `Cc: stable`, no `Reported-by:`, no `Tested-by:`
  (absence expected for manual review)

**Step 1.3:** Record: Bug: internal microphone not detected on ASUS
EXPERTBOOK BM1403CDA. Symptom: no audio capture device appears. Root
cause: this board's firmware/ACPI does not properly signal DMIC
presence, requiring a DMI override entry. No version information stated.

**Step 1.4:** Record: Not a hidden bug fix — it is an explicit hardware
quirk addition. This falls squarely into the "QUIRKS and WORKAROUNDS"
exception category for stable.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1:** Record: Single file changed:
`sound/soc/amd/yc/acp6x-mach.c`, +7 lines, 0 removed. Only
`yc_acp_quirk_table[]` static data modified. Scope: single-file, data-
only, surgical.

**Step 2.2:** Record: Before: BM1403CDA has no match in
`yc_acp_quirk_table[]`. After: a new entry matches `DMI_BOARD_VENDOR =
"ASUSTeK COMPUTER INC."` and `DMI_BOARD_NAME = "BM1403CDA"`, setting
`driver_data = &acp6x_card`. The new entry is inserted just before the
table terminator `{}`.

**Step 2.3:** Record: Category: Hardware workaround / DMI quirk table
entry. Mechanism: In `acp6x_probe()`, if ACPI methods (`_WOV` /
`AcpDmicConnected`) fail to enable the DMIC, the code falls through to
`check_dmi_entry` (line 761) where `dmi_first_match(yc_acp_quirk_table)`
is called. If matched, `platform_set_drvdata()` is set to `&acp6x_card`.
Without a match, `platform_get_drvdata()` returns NULL and
`acp6x_probe()` returns `-ENODEV` (line 768-769), meaning no sound card
is registered and the internal microphone is entirely absent.

Verified in the source:

```761:769:sound/soc/amd/yc/acp6x-mach.c
check_dmi_entry:
        /* check for any DMI overrides */
        dmi_id = dmi_first_match(yc_acp_quirk_table);
        if (dmi_id)
                platform_set_drvdata(pdev, dmi_id->driver_data);

        card = platform_get_drvdata(pdev);
        if (!card)
                return -ENODEV;
```

**Step 2.4:** Record: Obviously correct. The entry is structurally
identical to the 96 existing `driver_data = &acp6x_card` entries in the
same table, including sibling ASUS EXPERTBOOK models BM1503CDA and
PM1503CDA. Regression risk: zero for other hardware — the DMI match is
specific to one exact board vendor/name pair.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1:** Record: `git blame` shows the neighboring ASUS entries
were added by: `b671f9384ffc8` (Vivobook M6501RR, 2026-02-10),
`5a859a7dfce6c` (BM1503CDA, 2026-02-21), `355aab1aaf77d` (PM1503CDA,
2026-03-04). The table itself originates from `fa991481b8b22` ("ASoC:
amd: add YC machine driver using dmic", 2021-10-18), first appearing in
the v5.16 release cycle.

**Step 3.2:** Record: N/A — no `Fixes:` tag in the commit message.

**Step 3.3:** Record: Recent history of `acp6x-mach.c` is dominated by
single-entry DMI quirk additions for various laptop models (HP, ASUS,
Lenovo, Acer, MSI). This is a well-established, routine pattern. No
indication this patch is part of a multi-patch series requiring other
commits.

**Step 3.4:** Record: Vee Satayamas has no prior commits in
`sound/soc/amd/yc/` in this tree. However, the patch was reviewed by
Zhang Heng (who authored the PM1503CDA entry) and merged by Mark Brown
(ASoC maintainer), providing strong quality assurance.

**Step 3.5:** Record: No dependencies. The patch uses only existing
table infrastructure (`yc_acp_quirk_table[]`, `&acp6x_card`, `DMI_MATCH`
macros) that has been present since the driver was introduced in v5.16.
Fully standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.4:** Record: The commit references bugzilla.kernel.org bug
#221236 and a patch.msgid.link URL. External archive fetches are blocked
by Anubis challenge pages in this environment, so the exact mailing list
discussion and bugzilla details could not be retrieved. The commit
message itself documents the bug (internal mic not detected), the patch
was peer-reviewed (`Reviewed-by: Zhang Heng`) and merged by the ASoC
maintainer (`Signed-off-by: Mark Brown`). The message-id suffix `-2-`
suggests this may have been part of a small series, but the patch is
self-contained.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1:** Record: The diff modifies only the static data table
`yc_acp_quirk_table[]`. The runtime consumer is `acp6x_probe()`.

**Step 5.2:** Record: `acp6x_probe()` is the `.probe` callback of
`acp6x_mach_driver`, registered via `module_platform_driver()`. The
platform device `"acp_yc_mach"` is created by `snd_acp6x_probe()` in
`sound/soc/amd/yc/pci-acp6x.c` during PCI enumeration.

**Step 5.3:** Record: Within `acp6x_probe()`, key callees include
`ACPI_COMPANION()`, `acpi_dev_get_property()`,
`acpi_evaluate_integer()`, `dmi_first_match()`,
`platform_set_drvdata()`, and `devm_snd_soc_register_card()`. The quirk
only influences probe-time card selection.

**Step 5.4:** Record: Call chain: PCI enumeration → `snd_acp6x_probe()`
→ platform device registration → `acp6x_probe()` → DMI override → sound
card registration. Reachable automatically at boot on affected hardware.
Not a syscall-triggered path.

**Step 5.5:** Record: 96 existing `driver_data = &acp6x_card` entries in
the same file confirm this is the standard, well-tested pattern for
enabling DMIC on laptop models with broken/missing ACPI firmware
descriptions.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** Record: Verified via `git ls-tree`:
- `sound/soc/amd/yc/` is **absent** in v5.15
- Present since v5.16 (`fa991481b8b22`)
- Confirmed present in v6.1 and v6.6
- Fix is relevant to all active stable trees from v5.16 onward (6.1.y,
  6.6.y, 6.12.y, etc.)
- **Not applicable** to 5.15.y (driver does not exist there)

**Step 6.2:** Record: Expected clean apply or trivial context
adjustment. Older stable trees have shorter quirk tables, so the hunk
context will differ, but the semantic change is a single table entry
insertion before `{}` — trivial to backport.

**Step 6.3:** Record: No existing BM1403CDA entry found in git history.
No duplicate fix.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** Record: Subsystem: ASoC / AMD Yellow Carp (ACP6x) machine
driver. Criticality: IMPORTANT — audio is essential for laptop users;
this is a shipping ASUS business laptop model.

**Step 7.2:** Record: Highly active subsystem — recent history shows a
steady stream of DMI quirk additions for various laptop manufacturers.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Record: Platform-specific: affects owners of ASUS
EXPERTBOOK BM1403CDA with `CONFIG_SND_SOC_AMD_YC_MACH` enabled.

**Step 8.2:** Record: Trigger: deterministic on every boot of this
hardware. The internal microphone is permanently non-functional without
this quirk. Not timing-dependent.

**Step 8.3:** Record: Failure mode: internal microphone not detected
(probe returns `-ENODEV`). Severity: HIGH for affected users — complete
loss of audio capture functionality (no video calls, no voice
recording).

**Step 8.4:** Record: Benefit: HIGH for affected users (restores
essential hardware functionality). Risk: VERY LOW (7-line data-only
change, exact DMI match, no logic modification, identical pattern to 96
existing entries). Ratio: strongly favorable.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence compiled:**

FOR backporting:
- Real user-reported bug (bugzilla #221236)
- Fixes completely broken hardware (internal microphone non-functional)
- 7 lines added, single file, data-only change
- Zero regression risk (narrow DMI match, no logic change)
- Identical pattern to 96 existing quirk entries in the same table
- Reviewed by sibling-entry author (Zhang Heng) and merged by ASoC
  maintainer (Mark Brown)
- Driver and quirk infrastructure exist in all active stable trees
  (v6.1+, v6.6+)

AGAINST backporting:
- No evidence whatsoever against backporting

UNRESOLVED:
- Exact bugzilla details and mailing list discussion (blocked by Anubis)
- Whether the `-2-` message-id indicates a multi-patch series (but patch
  is self-contained)

**Step 9.2: Stable rules checklist:**
1. Obviously correct and tested? **YES** — identical to 96 existing
   entries; reviewed and merged by maintainer.
2. Fixes a real bug? **YES** — internal microphone not detected on
   shipping hardware.
3. Important issue? **YES** — complete hardware feature loss.
4. Small and contained? **YES** — 7 lines, one file, data-only.
5. No new features or APIs? **YES** — enables existing driver behavior
   for one board.
6. Can apply to stable? **YES** — for trees v5.16+ (6.1.y, 6.6.y, etc.);
   minor context adjustment may be needed.

**Step 9.3: Exception category:** Hardware quirk/workaround — DMI-based
enablement entry for an existing driver. This is explicitly listed as a
YES exception for stable.

**Step 9.4: Decision:** This is a textbook stable-backport DMI quirk.
Minimal risk, clear benefit, well-established pattern.

---

## Verification

- [Phase 1] Parsed commit message tags: found Link to bugzilla #221236,
  Reviewed-by Zhang Heng, merged by Mark Brown (ASoC maintainer)
- [Phase 2] Read `acp6x-mach.c` lines 695-779: verified existing ASUS
  entries at lines 706-719 and the DMI override path at lines 761-769
  (`dmi_first_match()` → `platform_set_drvdata()` → `-ENODEV` if no
  card)
- [Phase 2] Verified diff adds exactly one 7-line DMI table entry with
  no removals or logic changes
- [Phase 3] `git blame -L 700,730`: confirmed neighboring entries from
  `b671f9384ffc8`, `5a859a7dfce6c`, `355aab1aaf77d`; table terminator
  from `fa991481b8b22`
- [Phase 3] `git log --oneline -1 fa991481b8b22`: confirmed "ASoC: amd:
  add YC machine driver using dmic" introduced the driver
- [Phase 3] `git describe --contains fa991481b8b22`: confirmed driver
  first appears in v5.16-rc3 cycle
- [Phase 3] `git ls-tree v5.15 -- sound/soc/amd/yc/`: confirmed
  directory is **absent** in v5.15
- [Phase 3] `git ls-tree v5.16 -- sound/soc/amd/yc/`: confirmed
  directory is **present** in v5.16
- [Phase 3] `git log --oneline -20 -- sound/soc/amd/yc/acp6x-mach.c`:
  confirmed recent history is dominated by DMI quirk additions
- [Phase 5] `grep` count: verified 96 existing `driver_data =
  &acp6x_card` entries in the same file
- [Phase 6] `git ls-tree v6.1/v6.6 -- sound/soc/amd/yc/acp6x-mach.c`:
  confirmed file exists in both stable trees
- [Phase 4] UNVERIFIED: bugzilla.kernel.org and lore.kernel.org content
  blocked by Anubis; did not drive decision
- [Phase 3] UNVERIFIED: exact series context for `-2-` message-id
  suffix; patch is self-contained regardless

**YES**

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index 1324543b42d72..c536de1bb94ad 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -717,6 +717,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_BOARD_NAME, "PM1503CDA"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_BOARD_NAME, "BM1403CDA"),
+		}
+	},
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] dmaengine: idxd: Fix lockdep warnings when calling idxd_device_config()

[Sasha Levin]

From: Vinicius Costa Gomes <vinicius.gomes@intel.com>

[ Upstream commit caf91cdf2de8b7134749d32cd4ae5520b108abb7 ]

Move the check for IDXD_FLAG_CONFIGURABLE and the locking to "inside"
idxd_device_config(), as this is common to all callers, and the one
that wasn't holding the lock was an error (that was causing the
lockdep warning).

Suggested-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-1-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a thorough understanding of the code. Let me compile the
final analysis.

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**
Record: [dmaengine: idxd:] [Fix] [lockdep warnings when calling
idxd_device_config()] — "Fix" verb explicitly indicates a bug fix.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Suggested-by: Dave Jiang <dave.jiang@intel.com> — IDXD designated
  reviewer per MAINTAINERS
- Reviewed-by: Dave Jiang <dave.jiang@intel.com> — same person,
  subsystem expert
- Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> —
  author; listed as IDXD maintainer (M:) in MAINTAINERS
- Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-
  queues-v3-v3-1-7ed70658a9d1@intel.com
- Signed-off-by: Vinod Koul <vkoul@kernel.org> — dmaengine subsystem
  maintainer who applied it
- No Fixes:, Reported-by:, Tested-by:, or Cc: stable tags (expected)

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record: Bug = `idxd_device_config()` had
`lockdep_assert_held(&idxd->dev_lock)` but at least one caller was NOT
holding the lock. The commit message explicitly says "the one that
wasn't holding the lock was an error." Symptom = lockdep warnings at
runtime. Fix = move lock acquisition and `IDXD_FLAG_CONFIGURABLE` check
inside `idxd_device_config()` to centralize for all callers.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: This is explicitly labeled a "Fix" for lockdep warnings, but the
underlying issue is a real synchronization bug. The commit message says
the missing lock "was an error" — the function's callee contract
required `dev_lock` for device configuration MMIO/state writes, and at
least one caller violated it.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**
Record: 2 files: `drivers/dma/idxd/device.c` (3 hunks),
`drivers/dma/idxd/init.c` (1 hunk). Net change: approximately -5 lines.
Functions modified: `idxd_device_config()`, `idxd_drv_enable_wq()`,
`idxd_device_drv_probe()`, `idxd_reset_done()`. Scope: single-driver
surgical fix.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
- **Hunk 1 (idxd_device_config):**
  `lockdep_assert_held(&idxd->dev_lock)` replaced with
  `guard(spinlock)(&idxd->dev_lock)` (scope-based lock).
  `IDXD_FLAG_CONFIGURABLE` early-return check added. Lock is now
  acquired internally.
- **Hunk 2 (idxd_drv_enable_wq):** External `spin_lock/spin_unlock` +
  `IDXD_FLAG_CONFIGURABLE` check removed; direct call to
  `idxd_device_config()`.
- **Hunk 3 (idxd_device_drv_probe):** Same as Hunk 2.
- **Hunk 4 (idxd_reset_done in init.c):** Outer `IDXD_FLAG_CONFIGURABLE`
  guard removed; direct unconditional call.
- **Key insight:** The unmodified caller `idxd_device_reinit()` in
  `irq.c` (line 39) is automatically fixed because
  `idxd_device_config()` now acquires the lock internally.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: Synchronization / locking-contract bug. `idxd_device_config()`
asserted `lockdep_assert_held(&idxd->dev_lock)` but two callers violated
this: (1) `idxd_device_reinit()` in irq.c — present since v5.9, never
held the lock; (2) `idxd_reset_done()` in init.c — added in v6.14, also
didn't hold the lock. The fix centralizes lock acquisition inside the
callee.

**Step 2.4: ASSESS THE FIX QUALITY**
Record: Obviously correct — standard pattern of moving lock from callers
into callee. Uses well-established `guard(spinlock)` API. Minimal:
removes code from callers, adds to callee. Reviewed and suggested by the
IDXD designated reviewer (Dave Jiang). Very low regression risk — the
two callers that had the lock (drv_enable_wq, device_drv_probe) simply
shift the lock scope inside the function.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**
Record: `idxd_device_config()` with
`lockdep_assert_held(&idxd->dev_lock)` introduced by `bfe1d56091c1a4`
(Dave Jiang, 2020-01-21) — first appeared in v5.6. The unlocked
`idxd_device_reinit()` caller was introduced by `0d5c10b4c84d6a` (Dave
Jiang, 2020-06-26) — first appeared in v5.9. The unlocked
`idxd_reset_done()` caller from `98d187a9890360` (Fenghua Yu,
2024-11-22) — first appeared in v6.14.

**Step 3.2: FOLLOW THE FIXES TAG**
Record: No Fixes: tag present (expected — that's why this needs manual
review).

**Step 3.3: CHECK FILE HISTORY**
Record: Active idxd development. Recent commits include FLR support, UAF
fixes, deadlock fixes (`407171717a4f4`), spinlock-to-mutex conversions.
This fix is standalone.

**Step 3.4: CHECK THE AUTHOR**
Record: Vinicius Costa Gomes is the listed IDXD maintainer (M:) in
MAINTAINERS. Dave Jiang (Suggested-by/Reviewed-by) is the designated
reviewer (R:). Vinod Koul is the dmaengine subsystem maintainer who
applied it. Strong trust signal.

**Step 3.5: CHECK FOR DEPENDENCIES**
Record: Uses `guard(spinlock)` which requires `include/linux/cleanup.h`
— verified present in v6.6 (`cleanup.h` exists), NOT present in v6.1
(file does not exist at that tag). The `init.c` hunk only applies to
trees with FLR support (v6.14+). The `device.c` changes are standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.4:** Lore.kernel.org and patch.msgid.link URLs were blocked
by Anubis bot protection. The Link header indicates this is part of a
series related to "idxd-fix-flr-on-kernel-queues-v3." No stable-specific
discussion could be verified externally.

Record: UNVERIFIED — could not access lore/patch thread directly due to
anti-bot blocking.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: KEY FUNCTIONS**
Record: `idxd_device_config()`, `idxd_drv_enable_wq()`,
`idxd_device_drv_probe()`, `idxd_reset_done()`, and the unmodified but
affected `idxd_device_reinit()`.

**Step 5.2: TRACE CALLERS**
Verified all callers of `idxd_device_config()`:
1. `idxd_device_reinit()` in irq.c:39 — work queue callback for software
   reset recovery. **NO lock held — BUG (since v5.9)**
2. `idxd_reset_done()` in init.c:1097 — PCI FLR completion callback.
   **NO lock held — BUG (since v6.14)**
3. `idxd_drv_enable_wq()` in device.c:1455 — WQ enable path. Lock held
   correctly.
4. `idxd_device_drv_probe()` in device.c:1554 — Device driver probe.
   Lock held correctly.

**Step 5.3-5.4: CALL CHAINS**
- `idxd_device_reinit` ← `INIT_WORK` ← `idxd_halt()` ←
  `idxd_misc_thread()` (threaded IRQ handler via
  `request_threaded_irq`). Triggered when device enters halt state with
  software reset type.
- `idxd_reset_done` ← PCI error handler `.reset_done` callback.
  Triggered during FLR completion.
- Both are reachable during normal device operation under error/recovery
  conditions.

**Step 5.5: SIMILAR PATTERNS**
Record: Prior idxd locking fixes exist: `407171717a4f4` ("avoid deadlock
in process_misc_interrupts()") and `cf4ac3fef3388` (lockdep warning on
driver removal). This is a pattern in idxd of locking bugs being found
and fixed.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: BUGGY CODE IN STABLE TREES**
Verified:
- **v6.6:** `idxd_device_reinit()` calling `idxd_device_config()`
  without lock EXISTS (confirmed via `git show
  v6.6:drivers/dma/idxd/irq.c`). `idxd_reset_done()` does NOT exist
  (confirmed: `git grep idxd_device_config v6.6:drivers/dma/idxd/init.c`
  returns nothing).
- **v6.1:** Same unlocked `irq.c` caller exists, but `cleanup.h` /
  `guard(spinlock)` does NOT exist — backport would need traditional
  `spin_lock`/`spin_unlock`.
- **v6.14+:** Both buggy callers exist.

**Step 6.2: BACKPORT COMPLICATIONS**
- v6.6+: `guard(spinlock)` available. `device.c` changes apply cleanly.
  `init.c` hunk irrelevant (no FLR code).
- v6.1 and older: No `guard(spinlock)` — needs rework to explicit
  `spin_lock`/`spin_unlock`.

**Step 6.3: RELATED FIXES IN STABLE**
No prior fix for this specific `idxd_device_config()` lockdep/locking
issue found in stable.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** `drivers/dma/idxd` — Intel Data Streaming Accelerator
(DSA) / Intel Analytics Accelerator (IAA). Used in data center /
enterprise environments. Criticality: PERIPHERAL-to-IMPORTANT (hardware-
specific but used in enterprise/cloud computing).

**Step 7.2:** Actively maintained with regular bug fixes.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: WHO IS AFFECTED**
Record: Users of Intel IDXD/DSA/IAA hardware, primarily enterprise/data
center systems.

**Step 8.2: TRIGGER CONDITIONS**
Record: The `irq.c` unlocked path is triggered when the device enters
halt state and does a software reset (interrupt-driven). The `init.c`
path is triggered during FLR completion (v6.14+). These are error
recovery paths, not routine hot paths. However, they are reachable
during normal device operation when hardware issues occur.

**Step 8.3: FAILURE MODE SEVERITY**
The verified symptom is a lockdep warning. However, the missing lock on
`idxd_device_config()` means the function executes MMIO configuration
writes (`idxd_wqs_config_write`, `idxd_groups_config_write`) and
manipulates shared device state without the required `dev_lock`. This
creates a real (not theoretical) race window where concurrent access to
device configuration could cause incorrect MMIO programming or corrupted
device state. Severity: MEDIUM-HIGH — lockdep warning verified, race on
MMIO/config paths is the underlying risk.

**Step 8.4: RISK-BENEFIT RATIO**
- Benefit: MEDIUM-HIGH — fixes real synchronization bug that lockdep
  detected; prevents potential device misconfiguration during error
  recovery
- Risk: VERY LOW — net -5 lines, purely moves existing logic, reviewed
  by subsystem maintainer/reviewer
- Ratio: Strongly favorable

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: EVIDENCE FOR**
- Fixes a verified locking contract violation (lockdep_assert_held
  fails)
- The commit message explicitly says the missing lock "was an error"
- The unlocked `irq.c` caller has existed since v5.9 — long-standing bug
  affecting all stable trees with IDXD
- `idxd_device_config()` performs hardware MMIO writes — missing lock
  means real race on device state
- Small, surgical fix: net -5 lines, two files, single driver
- Written by the IDXD maintainer, suggested and reviewed by the IDXD
  designated reviewer
- Applied by the dmaengine subsystem maintainer
- Similar prior locking fixes in IDXD have been applied (e.g.,
  `407171717a4f4`)

**Step 9.2: EVIDENCE AGAINST**
- No verified crash, data corruption, or security issue — the verified
  symptom is a lockdep warning
- The init.c hunk only applies to v6.14+ (FLR code)
- v6.1 and older need rework (no `guard(spinlock)`)
- Niche hardware (Intel DSA/IAA, enterprise/data center)
- Could not verify mailing list discussion due to anti-bot blocking

**Step 9.3: STABLE RULES CHECKLIST**
1. Obviously correct and tested? **YES** — standard lock-inside-callee
   pattern, reviewed by subsystem expert
2. Fixes a real bug? **YES** — locking contract violation on hardware
   configuration path
3. Important issue? **YES** — race on MMIO/device configuration writes
   during error recovery; lockdep fires on any debug/CI kernel
4. Small and contained? **YES** — 2 files, net -5 lines, single driver
5. No new features or APIs? **YES** — pure bug fix
6. Can apply to stable? **YES** for v6.6+ (with init.c hunk dropped on
   pre-6.14); needs minor adaptation for v6.1

**Step 9.4: DECISION**
The fix addresses a real synchronization bug where device configuration
MMIO writes execute without the required `dev_lock`. The lockdep warning
is the verified symptom, but the underlying issue is a genuine race on
shared hardware state — missing locks on MMIO paths are not cosmetic.
The fix is small, obviously correct, and comes from the subsystem
maintainer chain. It meets all stable kernel criteria.

---

## Verification

- [Phase 1] Parsed all tags from commit message. Confirmed Vinicius
  Costa Gomes is IDXD maintainer (M:) and Dave Jiang is reviewer (R:) in
  MAINTAINERS file at line 12750-12752.
- [Phase 2] Read current `device.c` lines 1121-1145: confirmed
  `lockdep_assert_held(&idxd->dev_lock)` at line 1125.
- [Phase 2] Read current `device.c` lines 1452-1456: confirmed
  `idxd_drv_enable_wq()` takes `spin_lock(&idxd->dev_lock)` before
  calling `idxd_device_config()`.
- [Phase 2] Read current `device.c` lines 1552-1555: confirmed
  `idxd_device_drv_probe()` takes `spin_lock(&idxd->dev_lock)` before
  calling `idxd_device_config()`.
- [Phase 2] Read current `init.c` lines 1093-1102: confirmed
  `idxd_reset_done()` calls `idxd_device_config()` under
  `IDXD_FLAG_CONFIGURABLE` check but WITHOUT `dev_lock`.
- [Phase 2] Read current `irq.c` lines 32-64: confirmed
  `idxd_device_reinit()` calls `idxd_device_config()` at line 39 WITHOUT
  any lock and WITHOUT `IDXD_FLAG_CONFIGURABLE` check.
- [Phase 3] git blame `irq.c` lines 32-40: confirmed
  `idxd_device_reinit()` from commit `0d5c10b4c84d6a` (Dave Jiang,
  2020-06-26); `idxd_device_config()` call from `bfe1d56091c1a4`
  (2020-01-21).
- [Phase 3] git blame `device.c` lines 1121-1126: confirmed
  `idxd_device_config()` with `lockdep_assert_held` from
  `bfe1d56091c1a4`.
- [Phase 3] git blame `init.c` lines 1093-1102: confirmed
  `idxd_reset_done()` code from `98d187a9890360` (Fenghua Yu,
  2024-11-22).
- [Phase 3] `git describe --contains 0d5c10b4c84d6a` =
  `v5.9-rc1~96^2~1^2~52` — bug introduced in v5.9.
- [Phase 3] `git describe --contains 98d187a9890360` = `v6.14-rc1~43^2`
  — FLR caller introduced in v6.14.
- [Phase 3] `git describe --contains bfe1d56091c1a4` =
  `v5.6-rc1~196^2~7` — original function since v5.6.
- [Phase 5] Verified all callers via grep: `irq.c:39`, `init.c:1097`,
  `device.c:1455`, `device.c:1554`, `idxd.h:762` (declaration).
- [Phase 5] Read `irq.c` lines 400-421: verified `idxd_halt()` queues
  `idxd_device_reinit` via `INIT_WORK` + `queue_work` on software reset,
  and `idxd_device_flr` on FLR reset type.
- [Phase 6] `git show v6.6:drivers/dma/idxd/irq.c`: confirmed unlocked
  `idxd_device_reinit()` calling `idxd_device_config()` exists in v6.6.
- [Phase 6] `git show v6.6:drivers/dma/idxd/device.c` grep: confirmed
  `lockdep_assert_held` and locked callers exist in v6.6.
- [Phase 6] `git grep idxd_device_config v6.6:drivers/dma/idxd/init.c`:
  empty — FLR code does NOT exist in v6.6.
- [Phase 6] `git show v6.6:include/linux/cleanup.h`: exists —
  `guard(spinlock)` available in v6.6.
- [Phase 6] `git show v6.1:include/linux/cleanup.h`: does NOT exist —
  `guard(spinlock)` NOT available in v6.1.
- [Phase 8] Verified `idxd_device_config()` callees perform MMIO writes:
  `idxd_wqs_config_write()`, `idxd_groups_config_write()` at lines
  1136-1141.
- UNVERIFIED: Mailing list discussion content (lore blocked by Anubis
  anti-bot protection).
- UNVERIFIED: Whether an unprivileged user can reliably trigger the
  halt/software-reset path.

**YES**

 drivers/dma/idxd/device.c | 17 +++++++----------
 drivers/dma/idxd/init.c   | 10 ++++------
 2 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c
index c2cdf41b6e576..621f797b50d84 100644
--- a/drivers/dma/idxd/device.c
+++ b/drivers/dma/idxd/device.c
@@ -1122,7 +1122,11 @@ int idxd_device_config(struct idxd_device *idxd)
 {
 	int rc;
 
-	lockdep_assert_held(&idxd->dev_lock);
+	guard(spinlock)(&idxd->dev_lock);
+
+	if (!test_bit(IDXD_FLAG_CONFIGURABLE, &idxd->flags))
+		return 0;
+
 	rc = idxd_wqs_setup(idxd);
 	if (rc < 0)
 		return rc;
@@ -1449,11 +1453,7 @@ int idxd_drv_enable_wq(struct idxd_wq *wq)
 		}
 	}
 
-	rc = 0;
-	spin_lock(&idxd->dev_lock);
-	if (test_bit(IDXD_FLAG_CONFIGURABLE, &idxd->flags))
-		rc = idxd_device_config(idxd);
-	spin_unlock(&idxd->dev_lock);
+	rc = idxd_device_config(idxd);
 	if (rc < 0) {
 		dev_dbg(dev, "Writing wq %d config failed: %d\n", wq->id, rc);
 		goto err;
@@ -1549,10 +1549,7 @@ int idxd_device_drv_probe(struct idxd_dev *idxd_dev)
 	}
 
 	/* Device configuration */
-	spin_lock(&idxd->dev_lock);
-	if (test_bit(IDXD_FLAG_CONFIGURABLE, &idxd->flags))
-		rc = idxd_device_config(idxd);
-	spin_unlock(&idxd->dev_lock);
+	rc = idxd_device_config(idxd);
 	if (rc < 0)
 		return -ENXIO;
 
diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c
index 2acc34b3daff8..c29f9123934ae 100644
--- a/drivers/dma/idxd/init.c
+++ b/drivers/dma/idxd/init.c
@@ -1093,12 +1093,10 @@ static void idxd_reset_done(struct pci_dev *pdev)
 	idxd_device_config_restore(idxd, idxd->idxd_saved);
 
 	/* Re-configure IDXD device if allowed. */
-	if (test_bit(IDXD_FLAG_CONFIGURABLE, &idxd->flags)) {
-		rc = idxd_device_config(idxd);
-		if (rc < 0) {
-			dev_err(dev, "HALT: %s config fails\n", idxd_name);
-			goto out;
-		}
+	rc = idxd_device_config(idxd);
+	if (rc < 0) {
+		dev_err(dev, "HALT: %s config fails\n", idxd_name);
+		goto out;
 	}
 
 	/* Bind IDXD device to driver. */
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF

[Sasha Levin]

From: Zhang Heng <zhangheng@kylinos.cn>

[ Upstream commit 1f182ec9d7084db7dfdb2372d453c28f0e5c3f0a ]

Add a DMI quirk for the Thin A15 B7VF fixing the issue where
the internal microphone was not detected.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220833
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260316080218.2931304-1-zhangheng@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the evidence needed for a comprehensive analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [ASoC: amd: yc] [Add] [DMI quirk for MSI Thin A15 B7VF — enables
internal mic on this laptop model]

**Step 1.2: Tags**
Record:
- Link: `https://bugzilla.kernel.org/show_bug.cgi?id=220833` — user-
  filed bug report
- Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> — patch author
- Link: `https://patch.msgid.link/20260316080218.2931304-1-
  zhangheng@kylinos.cn` — mailing list submission
- Signed-off-by: Mark Brown <broonie@kernel.org> — ASoC subsystem
  maintainer (strong endorsement)
- No Fixes:, Cc: stable, Reported-by, Tested-by, or Reviewed-by —
  expected for this type of change
- Notable: Mark Brown is the ASoC maintainer, so his SOB indicates
  direct maintainer acceptance

**Step 1.3: Body Text**
Record: Bug: internal microphone not detected on MSI Thin A15 laptop.
Symptom: mic hardware present but invisible to the audio subsystem. No
version information provided. Root cause: DMI quirk table missing an
entry for this model.

**Step 1.4: Hidden Bug Fix Detection**
Record: Not hidden — this is explicitly a hardware quirk to enable an
existing audio path on a specific laptop. Without it, the internal
microphone is completely non-functional.

**Important discrepancy noted:** Subject says "Thin A15 B7VF" but the
code adds `DMI_MATCH(DMI_PRODUCT_NAME, "Thin A15 B7VE")`. Investigated
below.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: Single file: `sound/soc/amd/yc/acp6x-mach.c`. +7 lines added
(one new DMI table entry). Zero lines removed. Scope: single-file,
table-only change. No function bodies modified.

**Step 2.2: Code Flow Change**
Record: Before: `dmi_first_match(yc_acp_quirk_table)` in `acp6x_probe()`
has no entry matching this MSI model → probe returns `-ENODEV` or mic
card not registered → internal mic silent. After: DMI matches →
`platform_set_drvdata(pdev, dmi_id->driver_data)` sets `acp6x_card` →
`devm_snd_soc_register_card()` registers the audio card → internal mic
works.

**Step 2.3: Bug Mechanism**
Record: Category: Hardware workaround (DMI quirk table entry). The AMD
Yellow Carp DMIC driver requires either an ACPI property
(`AcpDmicConnected`) or a DMI quirk to enable the microphone. Many
laptops lack the ACPI property, so DMI matching is the fallback path.
This model needs that DMI entry.

**Step 2.4: Fix Quality**
Record: Obviously correct — identical pattern to 90+ other entries in
the same table. Minimal/surgical: 7 lines in a static const table.
Regression risk: zero — the new DMI entry only matches systems with both
`DMI_BOARD_VENDOR = "Micro-Star International Co., Ltd."` AND
`DMI_PRODUCT_NAME` containing `"Thin A15 B7VE"`. Cannot affect any other
hardware.

**B7VF vs B7VE discrepancy analysis:** MSI Thin A15 B7VE (RTX 4050,
Ryzen 5 7535HS) and B7VF (RTX 4060, Ryzen 7 7735HS) are confirmed to be
**distinct laptop models** per MSI's own specification sheets.
`DMI_MATCH()` uses `strstr()` (substring matching), verified in
`drivers/firmware/dmi_scan.c:865`. Since "Thin A15 B7VE" is NOT a
substring of "Thin A15 B7VF", the code targets only the B7VE model. The
commit subject's "B7VF" is almost certainly a typo — the author would
have used `dmidecode` output from their actual hardware to construct the
DMI match string, making the code correct for the B7VE model. The
maintainer (Mark Brown) accepted the patch, indicating the code was
tested.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: The DMI quirk table traces back to `fa991481b8b22` (v5.16 cycle,
Vijendar Mukunda). Recent entries from Zhang Heng (`355aab1aaf77d` —
PM1503CDA), and many others. The mechanism is long-standing.

**Step 3.2: Fixes Tag**
Record: N/A — no Fixes: tag present (expected for hardware quirk
additions).

**Step 3.3: File History**
Record: `git log --oneline -25` shows continuous DMI quirk additions:
PM1503CDA, BM1503CDA, HP 200 G2a 16, Acer TravelMate, Honor MagicBook,
HP Laptop 17, MSI Bravo 17 D7VF, etc. This is the same well-established
pattern.

**Step 3.4: Author**
Record: Zhang Heng has 2 prior commits in this subsystem
(`355aab1aaf77d` — ASUS PM1503CDA, `9502b7df5a3c7` — Acer TravelMate
P216-41-TCO). Regular contributor to this DMI quirk table.

**Step 3.5: Dependencies**
Record: None. The entry uses existing `acp6x_card` driver_data present
since the file's creation. Entirely self-contained.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Lore**
Record: Lore and patch.msgid.link blocked by Anubis bot protection.
Could not verify review discussion directly.

**Step 4.2: Bug Report**
Record: Bugzilla 220833 inaccessible (Anubis protection). However, the
bug report's existence is confirmed by the URL. Web search confirmed MSI
Thin A15 B7VE is a real laptop with RTX 4050/Ryzen 5 7535HS and B7VF is
a separate model with RTX 4060/Ryzen 7 7735HS.

**Step 4.3: Series Context**
Record: Single-patch submission (no "patch X/Y" indicator). Standalone
fix.

**Step 4.4: Stable List**
Record: Could not verify due to Anubis blocking. No existing `Thin A15`
entry found in git history (`git log --oneline --grep='Thin A15'`
returned empty).

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Symbols**
Record: `yc_acp_quirk_table[]` (data table), consumed by `acp6x_probe()`
via `dmi_first_match()`.

**Step 5.2: Callers**
Record: Table used only from `acp6x_probe()` at the `check_dmi_entry`
label (line 763). Driver is `module_platform_driver(acp6x_mach_driver)`
— runs at platform device probe.

**Step 5.3: Callees**
Record: `acp6x_probe()` calls `ACPI_COMPANION()`,
`acpi_dev_get_property()`, `acpi_evaluate_integer()`,
`dmi_first_match()`, `platform_set_drvdata()`, and
`devm_snd_soc_register_card()`.

**Step 5.4: Call Chain**
Record: PCI ACP device probe (`snd_acp6x_probe()` in `pci-acp6x.c`) →
registers `acp_yc_mach` platform device → `acp6x_probe()` → DMI match →
card registration. Reachable automatically at boot on matching hardware.

**Step 5.5: Similar Patterns**
Record: 5 existing MSI ("Micro-Star International") entries already in
the current tree: Bravo 15 B7ED, Bravo 15 C7VF, Bravo 17 D7VEK, Bravo 17
D7VF, Bravo 15 C7UCX. Identical pattern.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable?**
Record: File exists in v6.1 (270 lines), v6.6 (438 lines), v6.12 (586
lines). Does NOT exist in v5.15. The missing quirk affects all stable
trees that ship this driver (v6.1+).

**Step 6.2: Backport Complications**
Record: Expected clean apply or trivial context adjustment. The patch
appends one entry before the `{}` table terminator. The exact preceding
entries differ per stable tree, but this is a trivial context shift —
just place the new entry before `{}`.

**Step 6.3: Related Fixes in Stable**
Record: No existing `Thin A15` fix found in any tree.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
Record: ASoC / `sound/soc/amd/yc` — IMPORTANT for AMD laptop users.
Audio is a fundamental laptop feature.

**Step 7.2: Activity**
Record: Extremely active — 25+ recent commits, almost all DMI quirk
additions. One of the most frequently updated quirk tables in the
kernel.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Record: Owners of MSI Thin A15 B7VE laptops running Linux with
`CONFIG_SND_SOC_AMD_YC_MACH` enabled.

**Step 8.2: Trigger**
Record: Every boot on matching hardware. No special configuration or
privilege needed. The microphone is always broken without this quirk.

**Step 8.3: Failure Mode**
Record: Internal microphone completely non-functional. Severity: MEDIUM-
HIGH for affected users — a laptop with no working microphone is
significantly impaired for video calls, recording, accessibility.

**Step 8.4: Risk-Benefit Ratio**
Record:
- BENEFIT: High — restores fundamental hardware functionality for
  affected users
- RISK: Essentially zero — 7 lines in a static table, only matches one
  specific hardware model, cannot affect any other system
- Ratio: Extremely favorable

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compiled**

FOR backporting:
- Hardware quirk/workaround — explicit exception category (always
  appropriate for stable)
- Fixes real user-reported bug (bugzilla 220833) — internal mic non-
  functional
- Minimal change: +7 lines in a static DMI table
- Zero regression risk (DMI match is hardware-specific)
- Accepted by ASoC maintainer Mark Brown
- Identical pattern to 90+ other entries in the same table
- 5 existing MSI entries use the exact same pattern
- Driver exists in all active stable trees (v6.1+)
- No dependencies, fully self-contained

AGAINST backporting:
- Subject says "B7VF" but code targets "B7VE" — these are different MSI
  models. However, this is almost certainly a typo in the commit
  subject, not a code error. The author used the actual `dmidecode`
  output from their machine to construct the `DMI_MATCH` string.

UNRESOLVED:
- Could not access bugzilla 220833 or lore discussion to confirm the
  reporter's exact DMI strings
- The B7VF/B7VE discrepancy cannot be 100% resolved without the bug
  report

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivial table entry following
   established pattern; maintainer accepted
2. Fixes a real bug? **YES** — internal microphone not detected
3. Important issue? **YES** — hardware completely non-functional
4. Small and contained? **YES** — 7 lines, single static table
5. No new features or APIs? **YES** — extends existing quirk table only
6. Applies to stable? **YES** — driver present in v6.1+, trivial context
   adjustment at most

**Step 9.3: Exception Category**
Record: **Hardware quirk/workaround** (DMI-based) — explicitly listed as
appropriate for stable backporting.

**Step 9.4: Decision**
The B7VF/B7VE naming discrepancy is a cosmetic issue in the commit
message subject line, not a code correctness issue. The author would
have derived the DMI match string from their actual hardware's
`dmidecode` output — meaning the code targets the correct machine
(B7VE). The subject typo does not change the fact that this is a
standard, minimal, zero-risk hardware quirk addition that restores
microphone functionality on a specific laptop. Mark Brown (ASoC
maintainer) signed off on it. The patch follows the exact same pattern
as dozens of previously-backported quirk additions in the same file.
Even in the worst case (wrong DMI string), the patch is a harmless no-op
— it cannot cause any regression on any system.

## Verification

- [Phase 1] Parsed all tags from commit message: Link to bugzilla
  220833, author Zhang Heng, maintainer Mark Brown SOB
- [Phase 2] Diff: +7 lines adding one `struct dmi_system_id` entry to
  `yc_acp_quirk_table[]` for MSI "Thin A15 B7VE"
- [Phase 2] Verified `DMI_MATCH()` macro in
  `include/linux/mod_devicetable.h:601`: stores `.substr = b`
- [Phase 2] Verified `dmi_matches()` in
  `drivers/firmware/dmi_scan.c:865`: uses `strstr()` for non-exact
  matches
- [Phase 2] Therefore "Thin A15 B7VE" is NOT a substring of "Thin A15
  B7VF" — these target different hardware
- [Phase 2] Web search confirmed B7VE (RTX 4050) and B7VF (RTX 4060) are
  distinct MSI laptop models
- [Phase 3] `git log --oneline -25 -- sound/soc/amd/yc/acp6x-mach.c`:
  confirmed continuous DMI quirk addition pattern
- [Phase 3] `git log --author="Zhang Heng" -10 -- sound/soc/amd/yc/`: 2
  prior commits in subsystem
- [Phase 3] `git log --grep='Thin A15' --
  sound/soc/amd/yc/acp6x-mach.c`: no existing Thin A15 entry
- [Phase 4] Bugzilla/lore inaccessible due to Anubis bot protection
- [Phase 5] Read `acp6x_probe()`: confirmed
  `dmi_first_match(yc_acp_quirk_table)` at line 763, sets
  `platform_set_drvdata` from `driver_data`
- [Phase 5] grep for "Micro-Star": 5 existing MSI entries in the table
  already
- [Phase 6] File verified present in v6.1 (270 lines), v6.6 (438 lines),
  v6.12 (586 lines)
- [Phase 6] File does NOT exist in v5.15 (`fatal: path ... does not
  exist in 'v5.15'`)
- [Phase 6] MSI entries: 0 in v6.1, 1 in v6.6 — table framework exists
  in both
- [Phase 8] Failure mode: internal microphone completely non-functional
  on affected hardware
- [Phase 8] Risk: zero for non-matching hardware; worst case for
  matching hardware is a no-op
- UNVERIFIED: Exact contents of bugzilla 220833 (blocked by Anubis)
- UNVERIFIED: Exact lore discussion thread (blocked by Anubis)
- UNVERIFIED: Whether the reporter's machine is truly a B7VE or B7VF
  (most likely B7VE given the code)

This is a textbook stable backport candidate: a hardware quirk addition
to an existing driver's DMI table, fixing a real user-reported bug (non-
working internal microphone), with zero regression risk, accepted by the
subsystem maintainer.

**YES**

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index c536de1bb94ad..6f1c105ca77e3 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -724,6 +724,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_BOARD_NAME, "BM1403CDA"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Thin A15 B7VE"),
+		}
+	},
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.1] media: rkvdec: reduce stack usage in rkvdec_init_v4l2_vp9_count_tbl()

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit c03b7dec3c4ddc97872fa12bfca75bae9cb46510 ]

The deeply nested loop in rkvdec_init_v4l2_vp9_count_tbl() needs a lot
of registers, so when the clang register allocator runs out, it ends up
spilling countless temporaries to the stack:

drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c:966:12: error: stack frame size (1472) exceeds limit (1280) in 'rkvdec_vp9_start' [-Werror,-Wframe-larger-than]

Marking this function as noinline_for_stack keeps it out of
rkvdec_vp9_start(), giving the compiler more room for optimization.

The resulting code is good enough that both the total stack usage
and the loop get enough better to stay under the warning limit,
though it's still slow, and would need a larger rework if this
function ends up being called in a fast path.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

No existing stack fix in stable 6.6.y for this file. All the
investigation is complete. Let me now compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [media: rkvdec:] [reduce] [reduce stack usage in
rkvdec_init_v4l2_vp9_count_tbl() to fix Clang build failure with
-Wframe-larger-than]

**Step 1.2: Tags**
Record:
- Signed-off-by: Arnd Bergmann (author, well-known kernel build-fix
  expert)
- Reviewed-by: Nicolas Dufresne (Collabora, rkvdec contributor)
- Signed-off-by: Nicolas Dufresne (subsystem co-maintainer)
- Signed-off-by: Mauro Carvalho Chehab (media subsystem top-level
  maintainer)
- No Fixes:, Reported-by:, Tested-by:, Acked-by:, Link:, or Cc: stable
  (absence expected for this pipeline)

**Step 1.3: Commit Body**
Record: Bug: The deeply nested 5-level loop in
`rkvdec_init_v4l2_vp9_count_tbl()` uses many registers. When Clang
inlines it into `rkvdec_vp9_start()`, the combined stack frame reaches
1472 bytes, exceeding the 1280-byte `-Wframe-larger-than` limit.
Symptom: Build failure with `-Werror,-Wframe-larger-than`. Fix: Mark the
function `noinline_for_stack` to prevent inlining. Author notes the
resulting code is "good enough" and the function is not on a fast path.

**Step 1.4: Hidden Bug Fix Detection**
Record: This is an explicit build fix, not a disguised runtime fix. The
commit message is transparent about the problem and solution.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file changed (`drivers/media/platform/rockchip/rkvdec/rkvdec-
vp9.c`), ~2 lines modified (function signature only: `static void` ->
`static noinline_for_stack void` split across 2 lines). Function
modified: `rkvdec_init_v4l2_vp9_count_tbl()`. Scope: single-file,
absolutely surgical.

**Step 2.2: Code Flow Change**
Record: Before: `rkvdec_init_v4l2_vp9_count_tbl()` was a plain `static
void` function eligible for inlining into `rkvdec_vp9_start()`. After:
The `noinline_for_stack` attribute prevents inlining, so the function
gets its own stack frame. No logic, data flow, or error path changes
whatsoever.

**Step 2.3: Bug Mechanism**
Record: Category: build fix / compiler stack-usage mitigation. The
deeply nested loop (5 levels: `i`, `j`, `k`, `l`, `m`) with 6 pointer
dereference assignments per iteration exhausts Clang's register
allocator when inlined, causing heavy stack spilling that pushes the
caller's frame past the warning limit.

**Step 2.4: Fix Quality**
Record: Obviously correct. `noinline_for_stack` is a well-established,
documented kernel pattern (`include/linux/compiler_types.h` line
276-278: `#define noinline_for_stack noinline`). Zero regression risk --
the only effect is preventing inlining of a function called once during
VP9 decoder initialization, which is not a hot path. No API or
behavioral changes.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: `git blame` shows the entire function body traces to commit
`f25709c4ff151f` ("media: rkvdec: Add the VP9 backend") by Andrzej
Pietrasiewicz, dated 2021-11-17. This was included in
`v5.17-rc1~171^2~201`, so the code has been present since v5.17. The
same deeply nested loop and all 5 loop variables have been there since
introduction.

**Step 3.2: Fixes Tag**
Record: No Fixes: tag present (expected for commits under manual
review).

**Step 3.3: File History**
Record: On current tree, only 2 mainline commits modified `rkvdec-vp9.c`
in the non-staging path: the unstaging move (`d968e50b5c266`) and a QoS
disable (`664b42898db79`). The staging path has a few more minor
changes. No existing stack-usage or noinline fix for this file anywhere
in the history. The candidate is standalone.

**Step 3.4: Author Context**
Record: Arnd Bergmann is a prolific kernel contributor especially well-
known for build fixes, cross-compilation, architecture portability, and
stack-usage reduction patches. His media subsystem commits include
multiple similar `noinline_for_stack` fixes (e.g., `5954ad7d1af92` for
st-delta, `8b55f8818900c` for mediatek VP9). This is his core expertise.

**Step 3.5: Dependencies**
Record: No dependencies. `noinline_for_stack` is defined as `#define
noinline_for_stack noinline` in `include/linux/compiler_types.h` and has
existed since at least v4.x. The function signature is identical in all
stable trees (6.1.y, 6.6.y, 6.12.y) -- verified via `git show` on each
stable branch.

## PHASE 4: MAILING LIST RESEARCH

Record: Direct WebFetch to lore.kernel.org was blocked by Anubis proof-
of-work. However, the commit has proper review/signoff chain (Reviewed-
by from Nicolas Dufresne, Signed-off-by from both Nicolas Dufresne and
Mauro Carvalho Chehab), confirming it went through standard review.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions**
Record: Only `rkvdec_init_v4l2_vp9_count_tbl()` modified (signature
only).

**Step 5.2: Callers**
Record: Called exactly once from `rkvdec_vp9_start()` at line 1034.
Verified in all stable trees (6.1.y line 1031, 6.6.y/6.12.y line 1030).

**Step 5.3: Callees**
Record: The function sets up pointer tables and runs a 5-level nested
loop (`INNERMOST_LOOP` macro) performing array pointer assignments. No
dynamic allocations, no locks, no side effects beyond pointer setup.

**Step 5.4: Call Chain**
Record: `rkvdec_vp9_fmt_ops.start` -> `rkvdec_vp9_start()` ->
`rkvdec_init_v4l2_vp9_count_tbl()`. Called during VP9 streaming setup,
not per-frame. The author explicitly notes it is not a fast path.

**Step 5.5: Similar Patterns**
Record: `noinline_for_stack` is used in 7+ files under `drivers/media/`
for the same class of issue. The nearly identical mediatek VP9 commit
(`8b55f8818900c`) by the same author is the closest precedent.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code Existence**
Record: The file exists in all active stable trees:
- 6.1.y: `drivers/staging/media/rkvdec/rkvdec-vp9.c` (verified, function
  at line 927)
- 6.6.y: `drivers/staging/media/rkvdec/rkvdec-vp9.c` (verified, function
  at line 926)
- 6.12.y: `drivers/staging/media/rkvdec/rkvdec-vp9.c` (verified,
  function at line 926)
The function signature and the deeply nested loop are identical in all
branches.

**Step 6.2: Backport Complications**
Record: The file path differs in stable trees (staging vs non-staging),
requiring a trivial path adjustment. The actual code is functionally
identical -- the patch applies cleanly with a path change.

**Step 6.3: Precedent -- Critical Finding**
Record: The nearly identical mediatek VP9 `noinline_for_stack` commit by
the same author (`8b55f8818900c`) **was backported to all three stable
trees**:
- 6.1.y: `89e1132bbf713`
- 6.6.y: `fa43166f2e8ba`
- 6.12.y: `f87626a55c215`

This is extremely strong precedent. The rkvdec fix is the same type of
change (same author, same compiler issue, same annotation, same VP9
decoder context).

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
Record: `drivers/media/platform/rockchip/rkvdec/` -- Video decoder
driver for Rockchip SoCs. Criticality: PERIPHERAL (hardware-specific),
but Rockchip platforms are widely deployed in Chromebooks, single-board
computers, and embedded systems.

**Step 7.2: Activity**
Record: Low-moderate activity. The driver is mature. Recent changes are
minor (QoS fix, unstaging move).

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is Affected**
Record: Anyone building the kernel with Clang (especially with KASAN
enabled, based on the mediatek precedent) who enables
`CONFIG_VIDEO_ROCKCHIP_VDEC` or `COMPILE_TEST`. This includes CI
systems, distribution kernel builds, and embedded/Chromebook builders.

**Step 8.2: Trigger Conditions**
Record: Triggered at compile time with Clang + `-Wframe-larger-than` +
`-Werror`. Deterministic build failure. The specific Clang version and
configuration matter (KASAN amplifies the issue per the mediatek
precedent), but the fix is purely defensive and safe regardless.

**Step 8.3: Failure Mode**
Record: Build failure -- kernel cannot be compiled. For anyone who needs
this driver, it is a hard blocker. Severity: MEDIUM-HIGH (build failure,
not runtime crash, but prevents compilation entirely).

**Step 8.4: Risk-Benefit Ratio**
Record: BENEFIT: Fixes a real build failure for Clang users with common
warning configurations. The identical class of fix was already deemed
worthy of backport for the mediatek VP9 driver. RISK: Essentially zero.
Adding `noinline_for_stack` has no behavioral effect; it only affects
compiler inlining decisions. The function is called exactly once during
initialization. Ratio: Very favorable.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**

FOR backporting:
- Fixes a documented Clang `-Werror,-Wframe-larger-than` build failure
- Build fixes are an explicit exception category for stable backporting
- Extremely minimal change: single attribute annotation, no logic change
- Zero runtime regression risk
- Well-established kernel pattern (`noinline_for_stack`)
- Author is the recognized expert for this type of fix (Arnd Bergmann)
- Reviewed by subsystem co-maintainer, signed off by media subsystem
  top-level maintainer
- **Strong precedent**: nearly identical fix by same author for mediatek
  VP9 was backported to 6.1.y, 6.6.y, and 6.12.y
- Code exists in all active stable trees with identical function
  signature
- `noinline_for_stack` macro exists in all stable trees

AGAINST backporting:
- File path differs in stable (staging vs non-staging) -- requires
  trivial path adjustment
- Only affects Clang builds with specific configurations (not all build
  environments)
- The exact compiler version/config triggering the issue may vary

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** -- trivially correct, reviewed
   by maintainers
2. Fixes a real bug? **YES** -- build failure with Clang
3. Important issue? **YES** -- build failure prevents compilation
4. Small and contained? **YES** -- 2-line signature change
5. No new features or APIs? **YES** -- no new features
6. Can apply to stable? **YES** -- with path adjustment for staging
   directory

**Step 9.3: Exception Category**
Record: **BUILD FIX** -- explicitly listed as a valid stable exception
in the rules.

**Step 9.4: Decision**
This is a clear YES. It is a minimal, obviously correct build fix that
follows a well-established kernel pattern, was created by the foremost
expert in this area, and has direct precedent: the nearly identical
mediatek VP9 `noinline_for_stack` fix by the same author was already
backported to all active stable trees.

## Verification

- [Phase 1] Parsed subject: "media: rkvdec: reduce stack usage" -- build
  fix for Clang -Wframe-larger-than
- [Phase 1] Parsed tags: Reviewed-by Nicolas Dufresne, SOBs from
  subsystem and top-level maintainers, no Fixes/Reported-by (expected)
- [Phase 2] Diff analysis: 2-line change adding `noinline_for_stack` to
  `rkvdec_init_v4l2_vp9_count_tbl()` signature; no logic change
- [Phase 3] git blame: function introduced by `f25709c4ff151f` ("media:
  rkvdec: Add the VP9 backend", 2021-11-17), included since v5.17-rc1
- [Phase 3] git describe --contains f25709c4ff151f: confirmed
  `v5.17-rc1~171^2~201`
- [Phase 3] Verified `noinline_for_stack` defined in
  `include/linux/compiler_types.h` line 278 as `#define
  noinline_for_stack noinline`
- [Phase 3] Author check: Arnd Bergmann has multiple similar
  `noinline_for_stack` commits in drivers/media/
- [Phase 5] grep: `rkvdec_init_v4l2_vp9_count_tbl` called from exactly 1
  place: `rkvdec_vp9_start()` at line 1034
- [Phase 5] Read: confirmed 5-level nested loop (lines 973-997) with
  INNERMOST_LOOP macro causing heavy register pressure
- [Phase 6] git cat-file -e: verified file exists in 6.1.y, 6.6.y,
  6.12.y at staging path
- [Phase 6] git show on stable branches: verified function signature
  `static void rkvdec_init_v4l2_vp9_count_tbl(struct rkvdec_ctx *ctx)`
  is identical in 6.1.y (line 927), 6.6.y (line 926), 6.12.y (line 926)
  -- no `noinline_for_stack` present
- [Phase 6] Verified call site in 6.6.y stable at line 1030
- [Phase 6] **Critical precedent**: mediatek VP9 `noinline_for_stack`
  commit `8b55f8818900c` by same author backported to 6.1.y
  (`89e1132bbf713`), 6.6.y (`fa43166f2e8ba`), 6.12.y (`f87626a55c215`)
- [Phase 6] No existing stack-usage fix for rkvdec-vp9.c in any stable
  branch (verified via git log --grep="stack" on 6.6.y)
- [Phase 4] lore.kernel.org inaccessible (Anubis protection); review
  chain verified from commit tags
- UNVERIFIED: Mailing list discussion details beyond the commit tags
- UNVERIFIED: Exact Clang version/config that triggers the failure;
  however, the fix is defensive and safe regardless

**YES**

 drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c b/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c
index b4bf01e839eff..8fb6a1624a14f 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c
@@ -927,7 +927,8 @@ static void rkvdec_vp9_done(struct rkvdec_ctx *ctx,
 	update_ctx_last_info(vp9_ctx);
 }
 
-static void rkvdec_init_v4l2_vp9_count_tbl(struct rkvdec_ctx *ctx)
+static noinline_for_stack void
+rkvdec_init_v4l2_vp9_count_tbl(struct rkvdec_ctx *ctx)
 {
 	struct rkvdec_vp9_ctx *vp9_ctx = ctx->priv;
 	struct rkvdec_vp9_intra_frame_symbol_counts *intra_cnts = vp9_ctx->count_tbl.cpu;
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] btrfs: fix zero size inode with non-zero size after log replay

[Sasha Levin]

From: Filipe Manana <fdmanana@suse.com>

[ Upstream commit 5254d4181add9dfaa5e3519edd71cc8f752b2f85 ]

When logging that an inode exists, as part of logging a new name or
logging new dir entries for a directory, we always set the generation of
the logged inode item to 0. This is to signal during log replay (in
overwrite_item()), that we should not set the i_size since we only logged
that an inode exists, so the i_size of the inode in the subvolume tree
must be preserved (as when we log new names or that an inode exists, we
don't log extents).

This works fine except when we have already logged an inode in full mode
or it's the first time we are logging an inode created in a past
transaction, that inode has a new i_size of 0 and then we log a new name
for the inode (due to a new hardlink or a rename), in which case we log
an i_size of 0 for the inode and a generation of 0, which causes the log
replay code to not update the inode's i_size to 0 (in overwrite_item()).

An example scenario:

  mkdir /mnt/dir
  xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo

  sync

  xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo

  ln /mnt/dir/foo /mnt/dir/bar

  xfs_io -c "fsync" /mnt/dir

  <power fail>

After log replay the file remains with a size of 64K. This is because when
we first log the inode, when we fsync file foo, we log its current i_size
of 0, and then when we create a hard link we log again the inode in exists
mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we
add to the log tree, so during log replay overwrite_item() sees that the
generation is 0 and i_size is 0 so we skip updating the inode's i_size
from 64K to 0.

Fix this by making sure at fill_inode_item() we always log the real
generation of the inode if it was logged in the current transaction with
the i_size we logged before. Also if an inode created in a previous
transaction is logged in exists mode only, make sure we log the i_size
stored in the inode item located from the commit root, so that if we log
multiple times that the inode exists we get the correct i_size.

A test case for fstests will follow soon.

Reported-by: Vyacheslav Kovalevsky <slava.kovalevskiy.2014@gmail.com>
Link: https://lore.kernel.org/linux-btrfs/af8c15fa-4e41-4bb2-885c-0bc4e97532a6@gmail.com/
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: **[btrfs]** **[fix]** Incorrect inode `i_size` after log replay
— a file truncated to zero appears with its old non-zero size after
power failure and log replay, when a new name (hardlink/rename) is
logged for the inode.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reported-by:** Vyacheslav Kovalevsky
  \<slava.kovalevskiy.2014@gmail.com\> — a real user encountered this
  bug
- **Link:** https://lore.kernel.org/linux-
  btrfs/af8c15fa-4e41-4bb2-885c-0bc4e97532a6@gmail.com/ — bug report on
  the btrfs mailing list
- **Signed-off-by:** Filipe Manana \<fdmanana@suse.com\> — author,
  primary btrfs tree-log developer
- **Signed-off-by:** David Sterba \<dsterba@suse.com\> — btrfs
  maintainer
- No Fixes: tag (expected — this is why the commit is under manual
  review)
- No Cc: stable (expected)
- No Tested-by or Reviewed-by

Record: Single user reporter, fix from subsystem's primary tree-log
developer, accepted by maintainer.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit provides a concrete, reproducible scenario:
1. `mkdir /mnt/dir && xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo`
2. `sync`
3. `xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo` — truncates to 0,
   fsync logs the inode with `i_size = 0`
4. `ln /mnt/dir/foo /mnt/dir/bar` — creates a hard link, triggering
   LOG_INODE_EXISTS logging
5. `xfs_io -c "fsync" /mnt/dir` — syncs the directory log
6. Power failure → after log replay, file has 64K size instead of 0

**Root cause:** When logging "inode exists" (`LOG_INODE_EXISTS`),
`fill_inode_item()` always sets generation=0. During log replay,
`overwrite_item()` sees generation=0 and `ino_size=0` and skips updating
the subvolume tree's `i_size`. The file retains its stale pre-truncate
size.

Record: Data integrity bug — wrong file size after crash recovery. Clear
mechanism, reproducible, user-reported.

### Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not hidden — explicitly a correctness fix for log replay data
integrity.

---

## PHASE 2: DIFF ANALYSIS — LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File:** `fs/btrfs/tree-log.c` only
- **Functions modified:** `fill_inode_item()`, `logged_inode_size()` →
  renamed to `get_inode_size_to_log()`, `btrfs_log_inode()`
- **Scope:** ~70 lines changed across 3 hunks in a single file.
  Surgical, well-contained.

Record: Single-file fix, 3 functions modified, ~+55/-23 lines.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE

**Hunk 1 — `fill_inode_item()`:**
- **Before:** Always `btrfs_set_inode_generation(leaf, item, 0)` when
  `log_inode_only=true`.
- **After:** Default `gen` to the real inode generation. Only set
  generation to 0 if `logged_trans < trans->transid` (i.e., the inode
  was NOT already logged in the current transaction). If it WAS
  previously logged in this transaction, keep the real generation so
  replay will correctly apply the logged `i_size`.

**Hunk 2 — `logged_inode_size()` → `get_inode_size_to_log()`:**
- **Before:** Always searched the log tree; if item not found,
  `*size_ret = 0`.
- **After:** If inode was logged in the current transaction, searches
  the log tree (same as before). If inode is from a past transaction and
  not yet logged, searches the **commit root** of the subvolume tree. If
  inode was created in the current transaction and not yet logged,
  returns 0. Added ASSERT/WARN_ON_ONCE safety checks.

**Hunk 3 — `btrfs_log_inode()`:**
- **Before:** `if (inode_only == LOG_INODE_EXISTS &&
  ctx->logged_before)` — only fetched `logged_isize` if inode was logged
  before.
- **After:** `if (inode_only == LOG_INODE_EXISTS)` — always fetches the
  inode size to log, removing the `logged_before` guard. This ensures
  correct size even on the first exists-only log in a transaction.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category:** Logic/correctness fix — filesystem log replay invariant
violation leading to data inconsistency.

**Mechanism verified against `overwrite_item()` (lines 628-658 in
current tree):**

```644:658:fs/btrfs/tree-log.c
                if (btrfs_inode_generation(wc->log_leaf, src_item) == 0)
{
                        const u64 ino_size =
btrfs_inode_size(wc->log_leaf, src_item);
                        // ...
                        if (S_ISREG(btrfs_inode_mode(wc->log_leaf,
src_item)) &&
                            S_ISREG(btrfs_inode_mode(dst_eb, dst_item))
&&
                            ino_size != 0)
                                btrfs_set_inode_size(dst_eb, dst_item,
ino_size);
                        goto no_copy;
                }
```

When generation=0 AND `ino_size=0` (for a regular file), the size update
is skipped entirely and execution jumps to `no_copy`. This means the
subvolume tree's stale `i_size` (64K in the example) is preserved. The
fix ensures that when the inode was already logged in the same
transaction (with the truncated size), the real generation is used,
causing replay to take the full-copy path instead of the `no_copy` path.

### Step 2.4: ASSESS THE FIX QUALITY
- **Correctness:** The logic aligns with the documented
  `overwrite_item()` replay semantics. Using `logged_trans` to
  distinguish first-time vs. re-logging is consistent with existing
  patterns in `inode_logged()` (line 3744) which already uses
  `data_race(inode->logged_trans)`.
- **Minimality:** Well-contained to logging paths only.
- **Regression risk:** LOW — changes only affect the LOG_INODE_EXISTS
  code path (triggered by hard links, renames). The ASSERT and
  WARN_ON_ONCE provide debugging safety nets. No lock changes, no API
  changes.

Record: Fix is obviously correct when cross-referenced with
`overwrite_item()` replay code. Minimal regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
Verified via `git blame -L 4612,4625 fs/btrfs/tree-log.c`:
- The generation=0 logic was introduced by **`94edf4ae43a5f9`** (Josef
  Bacik, 2012-09-25) — "Btrfs: don't bother committing delayed inode
  updates when fsyncing"
- Lines 4620-4624 last touched by **`c418a1504540c6`** (David Sterba,
  2025-06-27) — cosmetic accessor conversion, not the logic origin.

Record: The buggy generation=0 behavior has existed since **2012**
(pre-v3.8). Present in ALL active stable trees.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present. N/A.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Verified recent related commits from the same reporter/timeframe:
- **`953902e4fb4c3`** — "btrfs: set inode flag
  BTRFS_INODE_COPY_EVERYTHING when logging new name" — different bug
  (names not persisted), touches `inode.c` and `tree-log.c`
- **`bfe3d755ef7ce`** — "btrfs: do not update last_log_commit when
  logging inode due to a new name" — different bug (directory fsync not
  persisting), 1-line change in `tree-log.c`

These are independent fixes for different bugs, all reported by the same
user during testing.

Record: Standalone fix. Not part of a series. Independent of the two
related commits above.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Filipe Manana is the primary btrfs tree-log developer. He authored
`logged_inode_size()` (commit `1a4bcf470c886`, v4.0) and most of the
tree-log fsync correctness fixes. David Sterba signed off as btrfs
maintainer.

Record: Author is THE subsystem expert for this code. Highest-confidence
authorship signal.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
- Uses `logged_trans`, `data_race()`, `search_commit_root`,
  `skip_locking` — all long-established.
- `ctx->logged_before` was introduced by **`0f8ce49821de3`** (Filipe
  Manana) in **v5.18-rc1**. This field exists in stable trees 6.1+ and
  later.
- `logged_inode_size()` was introduced by **`1a4bcf470c886`** in
  **v4.0-rc1**.

Record: Self-contained. Requires `ctx->logged_before` (v5.18+), so
applies to stable trees 6.1+.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.4: LORE RESEARCH
Both lore.kernel.org URLs returned Anubis bot protection (inaccessible).
The Link: tag in the commit confirms a real bug report exists on the
linux-btrfs mailing list from Vyacheslav Kovalevsky.

Record: Lore inaccessible. Bug report confirmed to exist via Link: tag.
UNVERIFIED: Full review discussion, any explicit stable nominations by
reviewers, any NAKs.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
Functions modified: `fill_inode_item()`, `logged_inode_size()` →
`get_inode_size_to_log()`, `btrfs_log_inode()`.

### Step 5.2: TRACE CALLERS
**`fill_inode_item()`** is called from:
1. `log_inode_item()` (line 4704) — with `log_inode_only=false` (NOT
   affected by this change)
2. `copy_inode_items_to_log()` (line 4966) — with `log_inode_only =
   (inode_only == LOG_INODE_EXISTS)` — **this is the affected path**

**`btrfs_log_inode()`** is called during fsync and directory logging.
The LOG_INODE_EXISTS path is triggered via `btrfs_log_new_name()`.

### Step 5.4: FOLLOW THE CALL CHAIN
Verified call chain for bug reachability:
- `link()` / `rename()` syscall → `btrfs_link()` / `btrfs_rename()` in
  `inode.c` → `btrfs_log_new_name()` (line 7931) → `btrfs_log_inode()`
  with `LOG_INODE_EXISTS` (line 6293) → `logged_inode_size()` (line
  6992) → `fill_inode_item()` (line 4966)

This is a **common userspace operation** — any unprivileged user can
trigger it with `link()` or `rename()` followed by `fsync()`.

Record: Bug reachable from common syscalls (link, rename, fsync).
Unprivileged users can trigger it.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
The `data_race(inode->logged_trans)` pattern already exists at line 3744
in `inode_logged()`. The new code follows the same established pattern.

Record: Consistent with existing code patterns.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
**Verified:** The pre-fix code (`logged_inode_size`, unconditional
generation=0 in `fill_inode_item`, `ctx->logged_before` guard) is still
present in the current tree (`v6.19.10`). `get_inode_size_to_log` does
not exist — the fix has NOT been applied yet.

- The generation=0 behavior dates to `94edf4ae43a5f9` (2012, pre-v3.8) —
  present in ALL stable trees.
- `logged_inode_size()` dates to `1a4bcf470c886` (v4.0) — present in all
  active stable trees.
- `ctx->logged_before` dates to `0f8ce49821de3` (v5.18) — present in
  6.1+ stable trees.

Record: All active stable trees (6.1+, 6.6+, 6.12+) contain the buggy
code.

### Step 6.2: BACKPORT COMPLICATIONS
`tree-log.c` has been actively modified (5+ recent commits since v6.12).
The patch modifies a function signature (`logged_inode_size` →
`get_inode_size_to_log`), changes the condition in `btrfs_log_inode`,
and restructures `fill_inode_item`. May require minor adaptation for
older stables, but the core logic should port cleanly.

Record: Expected backport difficulty: clean apply on recent stables
(6.12+), minor conflicts possible on older (6.1, 6.6).

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
No evidence that a different fix for the same bug exists. The confirmed
related commits (`953902e4fb4c3`, `bfe3d755ef7ce`) address different
bugs.

Record: No duplicate fix found.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM
**Subsystem:** fs/btrfs — filesystem layer, specifically the tree-log
(fsync journal) subsystem.
**Criticality:** IMPORTANT — btrfs is widely used, and crash recovery
correctness is fundamental to filesystem integrity. Wrong file sizes
after recovery = silent data corruption from the user's perspective.

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
`tree-log.c` is actively maintained with 30+ recent commits visible in
the log. This is a mature, well-maintained subsystem.

Record: Active subsystem, mature code, high importance for data
integrity.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
All btrfs users who rely on fsync for data integrity and who might
create hard links or rename files after truncating. This is a
fundamental filesystem operation.

Record: Affected population: all btrfs users (filesystem-specific but
btrfs is widely used).

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- **Trigger:** truncate file to 0 → fsync → create hard link or rename →
  fsync directory → power failure
- **How common:** Realistic workflow — the reporter hit it naturally
- **Unprivileged:** Yes, any user can trigger this with normal file
  operations

Record: Realistic trigger, unprivileged, discovered by a real user.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
When triggered: **File appears with wrong (old) size after crash
recovery.** The file was truncated to 0 but shows 64K after log replay.
This is **data integrity corruption** — the filesystem state after
recovery does not match what was committed via fsync.

Record: **Failure mode: data integrity violation (wrong file size after
crash).** **Severity: HIGH** — silent data corruption, stale data
visible, violates fsync durability contract.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
- **Benefit: HIGH** — prevents data corruption after crash recovery in a
  production filesystem. Fixes a violation of the fsync durability
  guarantee.
- **Risk: LOW** — ~70 lines in one file, authored by the subsystem
  expert, changes only the LOG_INODE_EXISTS logging path. Uses
  established patterns (`data_race(logged_trans)`). Includes
  ASSERT/WARN_ON safety nets. No lock changes, no API changes.
- **Net ratio: Strongly favorable for backporting.**

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a real, user-reported data integrity bug (wrong file size after
  crash recovery)
- Concrete, reproducible scenario provided in the commit message
- Verified against `overwrite_item()` replay code: generation=0 +
  ino_size=0 → skips `i_size` update → stale data preserved
- Authored by Filipe Manana, THE primary btrfs tree-log developer
- Accepted by David Sterba, btrfs maintainer
- Single file, ~70 lines, well-contained to logging paths
- Buggy code exists in ALL active stable trees (since 2012)
- Uses established patterns (`data_race(logged_trans)`)
- Trigger is realistic and reachable from unprivileged userspace
- Standalone fix with no dependencies beyond existing stable code

**AGAINST backporting:**
- Not trivial (not 1-5 lines) — moderate change size
- Function renamed and restructured (`logged_inode_size` →
  `get_inode_size_to_log`)
- May require minor adaptation for oldest stable trees
- Accesses commit root in a new code path (though safe and read-only)

**UNRESOLVED:**
- Lore discussion inaccessible (Anubis protection) — could not verify
  reviewer comments or explicit stable nominations
- Per-branch clean apply not verified

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES — logic verified against
   `overwrite_item()` replay code; authored by subsystem expert; fstests
   mentioned as follow-up
2. **Fixes a real bug that affects users?** YES — user-reported,
   reproducible, data integrity violation
3. **Important issue?** YES — data corruption (wrong file size after
   crash recovery) — HIGH severity
4. **Small and contained?** YES — single file, ~70 lines, 3 functions in
   tree-log.c
5. **No new features or APIs?** YES — purely a bug fix
6. **Can apply to stable trees?** YES — should apply to 6.1+ with
   possible minor adaptation for older trees

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not applicable — this is a standard data integrity bug fix, not an
exception category.

### Step 9.4: DECISION
This is a clear **YES**. It fixes a real, user-reported data integrity
bug where a file's size is incorrect after crash recovery. The fix is
well-contained, authored by the subsystem's primary developer, and meets
all stable kernel criteria. The risk-benefit ratio strongly favors
backporting.

---

## Verification

- **[Phase 1]** Parsed tags: found Reported-by: Vyacheslav Kovalevsky,
  Link: to lore.kernel.org bug report, Signed-off-by from Filipe Manana
  (author) and David Sterba (maintainer)
- **[Phase 2]** Diff analysis: ~70 lines in `fs/btrfs/tree-log.c`,
  modifies `fill_inode_item()`, `logged_inode_size()` →
  `get_inode_size_to_log()`, `btrfs_log_inode()`
- **[Phase 2]** Verified `overwrite_item()` log replay logic at lines
  644-658: generation=0 AND ino_size=0 → skips `btrfs_set_inode_size()`
  → goto `no_copy` → stale size preserved. Confirms the described bug
  mechanism.
- **[Phase 3]** `git blame -L 4612,4625`: generation=0 behavior from
  `94edf4ae43a5f9` (Josef Bacik, 2012-09-25) — present since pre-v3.8
- **[Phase 3]** `git log -S "logged_inode_size"`: introduced by
  `1a4bcf470c886` "Btrfs: fix fsync data loss after adding hard link to
  inode" — `git describe`: v4.0-rc1
- **[Phase 3]** `git log -S "ctx->logged_before"`: introduced by
  `0f8ce49821de3` — `git describe`: v5.18-rc1 — present in stable trees
  6.1+
- **[Phase 3]** Verified `953902e4fb4c3` and `bfe3d755ef7ce` are
  independent fixes for different bugs (same reporter)
- **[Phase 3]** Confirmed Filipe Manana is the primary tree-log
  developer (10+ recent commits in this file)
- **[Phase 4]** Lore.kernel.org inaccessible (Anubis bot protection) —
  UNVERIFIED: full review discussion, explicit stable nominations
- **[Phase 5]** `fill_inode_item()` called from
  `copy_inode_items_to_log()` at line 4966 with `log_inode_only =
  (inode_only == LOG_INODE_EXISTS)` — verified
- **[Phase 5]** Call chain: `link()/rename()` → `btrfs_log_new_name()`
  (line 7931) → `btrfs_log_inode()` → LOG_INODE_EXISTS path (line
  6978/6992) — confirmed reachable from unprivileged syscalls
- **[Phase 5]** `data_race(inode->logged_trans)` pattern already used at
  line 3744 in `inode_logged()` — consistent
- **[Phase 6]** `get_inode_size_to_log` does NOT exist in current tree —
  patch not yet applied. Pre-fix code (`logged_inode_size`,
  generation=0, `ctx->logged_before` guard) all confirmed present.
- **[Phase 6]** Buggy code exists in all active stable trees:
  generation=0 since 2012, `logged_inode_size` since v4.0,
  `ctx->logged_before` since v5.18
- **[Phase 8]** Failure mode: data integrity violation — wrong file size
  after crash recovery. Severity: HIGH.
- **UNVERIFIED:** Lore review discussion content. Per-branch clean apply
  testing. Runtime fstests validation.

**YES**

 fs/btrfs/tree-log.c | 98 ++++++++++++++++++++++++++++++---------------
 1 file changed, 65 insertions(+), 33 deletions(-)

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 6c40f48cc194d..4cea0489f121c 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4609,21 +4609,32 @@ static void fill_inode_item(struct btrfs_trans_handle *trans,
 			    struct inode *inode, bool log_inode_only,
 			    u64 logged_isize)
 {
+	u64 gen = BTRFS_I(inode)->generation;
 	u64 flags;
 
 	if (log_inode_only) {
-		/* set the generation to zero so the recover code
-		 * can tell the difference between an logging
-		 * just to say 'this inode exists' and a logging
-		 * to say 'update this inode with these values'
+		/*
+		 * Set the generation to zero so the recover code can tell the
+		 * difference between a logging just to say 'this inode exists'
+		 * and a logging to say 'update this inode with these values'.
+		 * But only if the inode was not already logged before.
+		 * We access ->logged_trans directly since it was already set
+		 * up in the call chain by btrfs_log_inode(), and data_race()
+		 * to avoid false alerts from KCSAN and since it was set already
+		 * and one can set it to 0 since that only happens on eviction
+		 * and we are holding a ref on the inode.
 		 */
-		btrfs_set_inode_generation(leaf, item, 0);
+		ASSERT(data_race(BTRFS_I(inode)->logged_trans) > 0);
+		if (data_race(BTRFS_I(inode)->logged_trans) < trans->transid)
+			gen = 0;
+
 		btrfs_set_inode_size(leaf, item, logged_isize);
 	} else {
-		btrfs_set_inode_generation(leaf, item, BTRFS_I(inode)->generation);
 		btrfs_set_inode_size(leaf, item, inode->i_size);
 	}
 
+	btrfs_set_inode_generation(leaf, item, gen);
+
 	btrfs_set_inode_uid(leaf, item, i_uid_read(inode));
 	btrfs_set_inode_gid(leaf, item, i_gid_read(inode));
 	btrfs_set_inode_mode(leaf, item, inode->i_mode);
@@ -5427,42 +5438,63 @@ static int btrfs_log_changed_extents(struct btrfs_trans_handle *trans,
 	return 0;
 }
 
-static int logged_inode_size(struct btrfs_root *log, struct btrfs_inode *inode,
-			     struct btrfs_path *path, u64 *size_ret)
+static int get_inode_size_to_log(struct btrfs_trans_handle *trans,
+				 struct btrfs_inode *inode,
+				 struct btrfs_path *path, u64 *size_ret)
 {
 	struct btrfs_key key;
+	struct btrfs_inode_item *item;
 	int ret;
 
 	key.objectid = btrfs_ino(inode);
 	key.type = BTRFS_INODE_ITEM_KEY;
 	key.offset = 0;
 
-	ret = btrfs_search_slot(NULL, log, &key, path, 0, 0);
-	if (ret < 0) {
-		return ret;
-	} else if (ret > 0) {
-		*size_ret = 0;
-	} else {
-		struct btrfs_inode_item *item;
+	/*
+	 * Our caller called inode_logged(), so logged_trans is up to date.
+	 * Use data_race() to silence any warning from KCSAN. Once logged_trans
+	 * is set, it can only be reset to 0 after inode eviction.
+	 */
+	if (data_race(inode->logged_trans) == trans->transid) {
+		ret = btrfs_search_slot(NULL, inode->root->log_root, &key, path, 0, 0);
+	} else if (inode->generation < trans->transid) {
+		path->search_commit_root = true;
+		path->skip_locking = true;
+		ret = btrfs_search_slot(NULL, inode->root, &key, path, 0, 0);
+		path->search_commit_root = false;
+		path->skip_locking = false;
 
-		item = btrfs_item_ptr(path->nodes[0], path->slots[0],
-				      struct btrfs_inode_item);
-		*size_ret = btrfs_inode_size(path->nodes[0], item);
-		/*
-		 * If the in-memory inode's i_size is smaller then the inode
-		 * size stored in the btree, return the inode's i_size, so
-		 * that we get a correct inode size after replaying the log
-		 * when before a power failure we had a shrinking truncate
-		 * followed by addition of a new name (rename / new hard link).
-		 * Otherwise return the inode size from the btree, to avoid
-		 * data loss when replaying a log due to previously doing a
-		 * write that expands the inode's size and logging a new name
-		 * immediately after.
-		 */
-		if (*size_ret > inode->vfs_inode.i_size)
-			*size_ret = inode->vfs_inode.i_size;
+	} else {
+		*size_ret = 0;
+		return 0;
 	}
 
+	/*
+	 * If the inode was logged before or is from a past transaction, then
+	 * its inode item must exist in the log root or in the commit root.
+	 */
+	ASSERT(ret <= 0);
+	if (WARN_ON_ONCE(ret > 0))
+		ret = -ENOENT;
+
+	if (ret < 0)
+		return ret;
+
+	item = btrfs_item_ptr(path->nodes[0], path->slots[0],
+			      struct btrfs_inode_item);
+	*size_ret = btrfs_inode_size(path->nodes[0], item);
+	/*
+	 * If the in-memory inode's i_size is smaller then the inode size stored
+	 * in the btree, return the inode's i_size, so that we get a correct
+	 * inode size after replaying the log when before a power failure we had
+	 * a shrinking truncate followed by addition of a new name (rename / new
+	 * hard link). Otherwise return the inode size from the btree, to avoid
+	 * data loss when replaying a log due to previously doing a write that
+	 * expands the inode's size and logging a new name immediately after.
+	 */
+	if (*size_ret > inode->vfs_inode.i_size)
+		*size_ret = inode->vfs_inode.i_size;
+
 	btrfs_release_path(path);
 	return 0;
 }
@@ -6975,7 +7007,7 @@ static int btrfs_log_inode(struct btrfs_trans_handle *trans,
 			ret = drop_inode_items(trans, log, path, inode,
 					       BTRFS_XATTR_ITEM_KEY);
 	} else {
-		if (inode_only == LOG_INODE_EXISTS && ctx->logged_before) {
+		if (inode_only == LOG_INODE_EXISTS) {
 			/*
 			 * Make sure the new inode item we write to the log has
 			 * the same isize as the current one (if it exists).
@@ -6989,7 +7021,7 @@ static int btrfs_log_inode(struct btrfs_trans_handle *trans,
 			 * (zeroes), as if an expanding truncate happened,
 			 * instead of getting a file of 4Kb only.
 			 */
-			ret = logged_inode_size(log, inode, path, &logged_isize);
+			ret = get_inode_size_to_log(trans, inode, path, &logged_isize);
 			if (ret)
 				goto out_unlock;
 		}
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx

[Sasha Levin]

From: César Montoya <sprit152009@gmail.com>

[ Upstream commit 2f388b4e8fdd6b0f27cafd281658daacfd85807e ]

The HP Pavilion 15-eg0xxx with subsystem ID 0x103c87cb uses a Realtek
ALC287 codec with a mute LED wired to GPIO pin 4 (mask 0x10). The
existing ALC287_FIXUP_HP_GPIO_LED fixup already handles this correctly,
but the subsystem ID was missing from the quirk table.

GPIO pin confirmed via manual hda-verb testing:
  hda-verb SET_GPIO_MASK 0x10
  hda-verb SET_GPIO_DIRECTION 0x10
  hda-verb SET_GPIO_DATA 0x10

Signed-off-by: César Montoya <sprit152009@gmail.com>
Link: https://patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

All verification is complete. Here is the full analysis.

---

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**
Record: [ALSA: hda/realtek] [Add] [mute LED quirk for HP Pavilion
15-eg0xxx — adds missing PCI subsystem ID to the Realtek ALC287 quirk
table]

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Signed-off-by: César Montoya `<sprit152009@gmail.com>` — patch author
  / hardware owner
- Link: `https://patch.msgid.link/20260321153603.12771-1-
  sprit152009@gmail.com` — submission link
- Signed-off-by: Takashi Iwai `<tiwai@suse.de>` — ALSA/HDA subsystem
  maintainer (applied the patch)
- No Fixes: tag (expected — quirk additions rarely have one)
- No Reported-by: (author IS the affected user)
- No Cc: stable (absence expected for commits under review)

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record: Bug: HP Pavilion 15-eg0xxx with subsystem ID 0x103c:0x87cb uses
ALC287 codec with mute LED wired to GPIO pin 4 (mask 0x10). The existing
`ALC287_FIXUP_HP_GPIO_LED` fixup already handles this correctly, but the
subsystem ID was missing from the quirk table. Symptom: mute LED does
not function at all. Root cause: missing SSID→fixup mapping. Evidence:
author confirms GPIO pin via manual `hda-verb` testing (SET_GPIO_MASK,
SET_GPIO_DIRECTION, SET_GPIO_DATA with 0x10).

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not a hidden bug fix — this is an explicit hardware quirk
addition (a well-known stable exception category). The "bug" is that
hardware doesn't work without the quirk table entry.

===============================================================
PHASE 2: DIFF ANALYSIS — LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**
Record: 1 file changed: `sound/hda/codecs/realtek/alc269.c`. +1 line, -0
lines. Function modified: none (data table `alc269_fixup_tbl[]` only).
Scope: single-file, single table row — maximally surgical.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record: Before: subsystem ID 0x103c:0x87cb is not in
`alc269_fixup_tbl[]`, so the HDA core finds no fixup match during codec
probe, and the mute LED is never configured. After: the new
`SND_PCI_QUIRK(0x103c, 0x87cb, "HP Pavilion 15-eg0xxx",
ALC287_FIXUP_HP_GPIO_LED)` entry causes `snd_hda_pick_fixup()` to match
and apply the GPIO LED fixup during probe.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: Category (h) — hardware workaround / quirk table entry. The
added line is inserted in sorted order between 0x87c8 and 0x87cc (the
latter is the same laptop model name using the same fixup). The fixup
`ALC287_FIXUP_HP_GPIO_LED` is defined at line 5921 and calls
`alc287_fixup_hp_gpio_led()`, which invokes
`alc_fixup_hp_gpio_led(codec, action, 0x10, 0)` — GPIO mask 0x10 exactly
matches the commit message's hda-verb testing.

**Step 2.4: ASSESS THE FIX QUALITY**
Record: Obviously correct — identical pattern to the neighboring 0x87cc
entry for the same laptop model. Regression risk: effectively zero — the
quirk only activates on machines with PCI subsystem ID 0x103c:0x87cb. No
logic, no API, no code flow changes. No red flags.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**
Record: `git blame -L6868,6872` shows:
- Line 6869 (0x87c8): from `aeeb85f26c3bbe` (Takashi Iwai, 2025-07-09) —
  the mass file relocation commit
- Line 6870 (0x87cc): from `7cd3c8cafbc050` (Takashi Iwai, 2025-07-21) —
  merge of `9744ede7099e8` which added the 0x87cc entry
- The 0x87cb line does not exist in this tree (this is the candidate
  commit adding it)

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: N/A — no Fixes: tag. Expected for quirk additions.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: The related commit `9744ede7099e8` ("ALSA: hda/realtek - Add
mute LED support for HP Pavilion 15-eg0xxx") added the 0x87cc entry for
the same laptop model, was written by a different author (Dawid Rezler),
explicitly carried `Cc: <stable@vger.kernel.org>`, and went into
`sound/pci/hda/patch_realtek.c` (pre-move path). It was tagged
`v6.16~13^2~3`, meaning it entered in v6.16. The current commit adds a
sibling SSID (0x87cb) for the same model. Standalone — no other patches
needed.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: César Montoya appears to be an end-user / first-time contributor
fixing their own hardware. Patch was accepted and signed off by Takashi
Iwai (ALSA maintainer), lending strong confidence.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: The only prerequisite is `ALC287_FIXUP_HP_GPIO_LED` and its
implementation `alc287_fixup_hp_gpio_led()`. These were introduced long
ago and exist in all active stable trees. No other dependencies. Fully
standalone.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: SEARCH LORE.KERNEL.ORG**
Record: The commit includes a Link to
`patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com`. The
patch was a single standalone submission (not a series — "12771-1" with
no further parts). Takashi Iwai's Signed-off-by indicates direct
application by the maintainer. No NAKs or objections are evident from
the acceptance.

**Step 4.2: SEARCH FOR BUG REPORT**
Record: No separate bug report — the author is the affected user who
submitted the fix directly, confirmed via hda-verb hardware testing.

**Step 4.3: CHECK FOR RELATED PATCHES AND SERIES**
Record: Standalone single patch. The sibling 0x87cc entry (commit
`9744ede7099e8`) was a separate patch from a different author and
already carried `Cc: stable`.

**Step 4.4: CHECK STABLE MAILING LIST HISTORY**
Record: The sibling commit `9744ede7099e8` for 0x87cc already has `Cc:
stable@vger.kernel.org`, confirming the subsystem maintainer considers
this class of quirk appropriate for stable backporting.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: No functions modified. Only a data table entry added to
`alc269_fixup_tbl[]`.

**Step 5.2: TRACE CALLERS**
Record: The table is consumed by `snd_hda_pick_fixup()` during Realtek
ALC269-family codec probe. This is a standard, well-tested code path run
once per codec initialization.

**Step 5.3: TRACE CALLEES**
Record: When matched, the fixup definition at line 5921 invokes
`alc287_fixup_hp_gpio_led()` (line 1360), which calls
`alc_fixup_hp_gpio_led(codec, action, 0x10, 0)`. This configures GPIO
pin 4 for the mute LED — a well-tested helper used by many HP models.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Codec probe → `snd_hda_pick_fixup()` → table lookup →
`ALC287_FIXUP_HP_GPIO_LED` → `alc287_fixup_hp_gpio_led()` →
`alc_fixup_hp_gpio_led()`. The path is reachable on every boot for users
with this hardware.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: `ALC287_FIXUP_HP_GPIO_LED` appears 11 times in the file. At
least 10 other HP models use the identical fixup. This is a massively
replicated, well-tested pattern.

===============================================================
PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
Record: The `ALC287_FIXUP_HP_GPIO_LED` fixup and its implementation have
been in the tree since at least v5.10-era kernels. All active stable
trees (6.1.y, 6.6.y, 6.12.y, etc.) contain the fixup infrastructure. The
only thing missing is this specific SSID table entry.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: The file was moved from `sound/pci/hda/patch_realtek.c` to
`sound/hda/codecs/realtek/alc269.c` in commit `6014e9021b28e`
(v6.17-rc1). Stable trees older than 6.17 need the patch applied to the
old path. The table format is identical in both locations. The fix is a
single line addition at a predictable sorted location — trivial to
adjust for either path.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE**
Record: The 0x87cb SSID does not appear in the current tree (confirmed
by grep), so no related fix for this specific SSID is already present.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: Subsystem: sound/hda (HD-Audio, Realtek codec). Criticality:
IMPORTANT — audio is critical for laptop users. This specific driver
covers a very large number of consumer laptops.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Extremely active — `git log` shows continuous stream of quirk
additions. Takashi Iwai actively maintains and applies these patches.
Quirk additions for HP laptops are the most common type of commit in
this file.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Users of HP Pavilion 15-eg0xxx laptops with PCI subsystem ID
0x103c:0x87cb and ALC287 codec. Platform-specific / driver-specific.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Every boot on affected hardware. The mute LED never works
without this quirk — it's not intermittent, it's permanent broken
behavior for these users.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Without the fix, the mute LED does not respond. Severity: LOW
for system stability (no crash/corruption), but this is a real hardware
defect that makes the laptop's audio indicator non-functional. This is
exactly the class of hardware enablement quirk that stable trees
routinely accept.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record: Benefit: enables mute LED for a specific HP laptop variant —
real hardware fix for real users. Risk: essentially zero — the
`SND_PCI_QUIRK` entry only matches on the exact subsystem ID
0x103c:0x87cb, and the underlying fixup is well-tested across 10+ other
HP models. Risk-benefit ratio: very favorable.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

Evidence FOR backporting:
- Single-line `SND_PCI_QUIRK` table entry addition — textbook stable
  material
- Uses existing, well-tested fixup (`ALC287_FIXUP_HP_GPIO_LED`)
  confirmed in 10+ other entries
- GPIO mask 0x10 in the fixup matches the author's hda-verb hardware
  verification
- Neighboring entry 0x87cc for the same laptop model uses the identical
  fixup
- The sibling 0x87cc commit (`9744ede7099e8`) explicitly carries `Cc:
  stable@vger.kernel.org`
- Accepted by ALSA maintainer Takashi Iwai
- Fixup infrastructure exists in all active stable trees (since
  v5.10-era)
- Zero regression risk (SSID-gated, affects only this specific hardware)
- Matches the "AUDIO CODEC QUIRKS" exception category explicitly listed
  in stable guidelines

Evidence AGAINST backporting:
- None

Unresolved:
- Full mailing list thread content not fetched (but maintainer
  acceptance is confirmed via SOB)

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **YES** — identical pattern to dozens
   of entries; hardware-verified by author via hda-verb; accepted by
   subsystem maintainer
2. Fixes a real bug that affects users? **YES** — mute LED non-
   functional on specific HP laptop
3. Important issue? **YES under exception** — hardware quirk for audio
   codec; same class as the explicitly allowed "SND_PCI_QUIRK entries
   for specific laptop models"
4. Small and contained? **YES** — 1 line, single table entry
5. No new features or APIs? **YES** — maps an existing fixup to a new
   SSID
6. Can apply to stable trees? **YES** — trivially, with path adjustment
   for trees < v6.17 (`sound/pci/hda/patch_realtek.c` instead of
   `sound/hda/codecs/realtek/alc269.c`)

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: Hardware quirk / audio codec quirk — explicitly listed as
automatic YES in stable guidelines. `SND_PCI_QUIRK` entries for specific
laptop models are called out by name.

**Step 9.4: MAKE YOUR DECISION**
This is a textbook hardware quirk addition — a single-line
`SND_PCI_QUIRK` entry mapping a missing PCI subsystem ID to an existing,
well-tested fixup function. It enables the mute LED on a specific HP
laptop variant. Zero regression risk, accepted by the subsystem
maintainer, underlying fixup exists in all active stable trees.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by from author (César Montoya) and
  maintainer (Takashi Iwai); Link to patch submission; no
  Fixes:/Reported-by: (expected for quirk)
- [Phase 2] Diff: exactly +1 line `SND_PCI_QUIRK(0x103c, 0x87cb, "HP
  Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED)` in
  `alc269_fixup_tbl[]`
- [Phase 3] git blame -L6868,6872: confirmed 0x87cc at line 6870 from
  `7cd3c8cafbc050`, surrounding lines from `aeeb85f26c3bbe` (file move);
  0x87cb not present in current tree (grep returns no matches)
- [Phase 3] git show `9744ede7099e8`: confirmed this is the sibling
  0x87cc commit for the same laptop model, with `Cc:
  <stable@vger.kernel.org>`, tagged `v6.16~13^2~3`
- [Phase 3] git show `6014e9021b28e`: confirmed file moved from
  `sound/pci/hda/patch_realtek.c` to `sound/hda/codecs/realtek/alc269.c`
  in v6.17-rc1
- [Phase 5] Read lines 1360-1364: `alc287_fixup_hp_gpio_led()` calls
  `alc_fixup_hp_gpio_led(codec, action, 0x10, 0)` — GPIO mask 0x10
  matches commit message
- [Phase 5] Read lines 5921-5924: `ALC287_FIXUP_HP_GPIO_LED` fixup
  definition confirmed, type `HDA_FIXUP_FUNC`
- [Phase 5] Grep: `ALC287_FIXUP_HP_GPIO_LED` appears 11 times in
  alc269.c (10+ other HP models)
- [Phase 6] File path differs between mainline and stable < 6.17; table
  format is identical — trivial backport adjustment
- [Phase 8] Risk: zero (SSID-gated single table entry, well-tested
  existing fixup path)

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 75f880efdeaf1..5adc5db6fd52b 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6868,6 +6868,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8788, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x87b7, "HP Laptop 14-fq0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
 	SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x87cb, "HP Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x87cc, "HP Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x87d3, "HP Laptop 15-gw0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
 	SND_PCI_QUIRK(0x103c, 0x87df, "HP ProBook 430 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED),
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry

[Sasha Levin]

From: Florian Westphal <fw@strlen.de>

[ Upstream commit d3c0037ffe1273fa1961e779ff6906234d6cf53c ]

New test case fails unexpectedly when avx2 matching functions are used.

The test first loads a ranomly generated pipapo set
with 'ipv4 . port' key, i.e.  nft -f foo.

This works.  Then, it reloads the set after a flush:
(echo flush set t s; cat foo) | nft -f -

This is expected to work, because its the same set after all and it was
already loaded once.

But with avx2, this fails: nft reports a clashing element.

The reported clash is of following form:

    We successfully re-inserted
      a . b
      c . d

Then we try to insert a . d

avx2 finds the already existing a . d, which (due to 'flush set') is marked
as invalid in the new generation.  It skips the element and moves to next.

Due to incorrect masking, the skip-step finds the next matching
element *only considering the first field*,

i.e. we return the already reinserted "a . b", even though the
last field is different and the entry should not have been matched.

No such error is reported for the generic c implementation (no avx2) or when
the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback.

Bisection points to
7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection")
but that fix merely uncovers this bug.

Before this commit, the wrong element is returned, but erronously
reported as a full, identical duplicate.

The root-cause is too early return in the avx2 match functions.
When we process the last field, we should continue to process data
until the entire input size has been consumed to make sure no stale
bits remain in the map.

Link: https://lore.kernel.org/netfilter-devel/20260321152506.037f68c0@elisabeth/
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

All verified. Now I have the complete and verified picture. Let me write
the final answer.

===============================================================
## PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: Subject Line**
Record: [netfilter: nft_set_pipapo_avx2] [don't return / fix] [Prevent
AVX2 pipapo lookup helpers from returning a non-matching entry when an
expired/invalid element is skipped]

**Step 1.2: Tags**
Record:
- Link: `https://lore.kernel.org/netfilter-
  devel/20260321152506.037f68c0@elisabeth/`
- Signed-off-by: Florian Westphal `<fw@strlen.de>` (author, netfilter
  maintainer)
- Reviewed-by: Stefano Brivio `<sbrivio@redhat.com>` (original author of
  pipapo AVX2 implementation)
- Signed-off-by: Pablo Neira Ayuso `<pablo@netfilter.org>` (netfilter
  subsystem maintainer)
- No Fixes: tag (expected for manual review)
- No Reported-by: tag
- No Cc: stable (expected for manual review)
Notable: Reviewed by the original pipapo AVX2 code author — strong
correctness signal for this specialized code.

**Step 1.3: Commit Body Analysis**
Record: [Bug: After flushing and reloading a pipapo set with multi-field
keys (e.g., `ipv4 . port`), the AVX2 code incorrectly reports element
clashes] [Symptom: `nft -f` fails with clash error on valid set reload]
[Root cause: Early `return b` in AVX2 helper functions when processing
the last field causes the loop to exit before all 256-bit map chunks are
processed, leaving stale bits from previous field matching. When an
expired/inactive element is skipped via `pipapo_refill()`, those stale
bits produce matches based only on the first key field, returning
incorrect elements] [Bisection points to 7711f4bb4b36 which merely
exposed the bug]

**Step 1.4: Hidden Bug Fix Detection**
Record: Not hidden — the commit message explicitly describes a concrete
bug with a clear reproducer and root-cause explanation.

===============================================================
## PHASE 2: DIFF ANALYSIS
===============================================================

**Step 2.1: Inventory**
Record: Single file changed: `net/netfilter/nft_set_pipapo_avx2.c`. 10
identical one-token changes across 10 functions:
`nft_pipapo_avx2_lookup_4b_{2,4,8,12,32}` and
`nft_pipapo_avx2_lookup_8b_{1,2,4,6,16}`. Each changes `return b;` to
`ret = b;`. Scope: single-file surgical fix.

**Step 2.2: Code Flow Change**
Record: For each of the 10 hunks: Before — when processing the last
field (`last == true`) and a match is found via
`nft_pipapo_avx2_refill()`, the helper immediately returns `b`, skipping
processing of remaining 256-bit chunks. After — the match index is
stored in `ret` and the loop continues via `continue`, processing all
remaining chunks (clearing/updating the map for each). The function
returns `ret` at the end of the loop (line unchanged). This ensures the
full bitmap is consistent before the caller uses it.

**Step 2.3: Bug Mechanism**
Record: [Category: Logic/state correctness bug in bitmap processing] The
AVX2 helpers process the result map in `m256_size` chunks. When the last
field is being processed and a match is found in chunk `i`, the early
`return b` skips chunks `i+1`, `i+2`, etc. Those chunks retain stale
bits from the previous field's matching. When `pipapo_get_avx2()` (line
1240-1244) finds the matched element is expired/inactive and calls
`pipapo_refill()` on the same `res` map, those stale bits are found and
return incorrect matches that match only on a subset of key fields. The
generic C path and `nft_pipapo_avx2_lookup_slow` don't have this issue
because they process the full map in one pass.

**Step 2.4: Fix Quality**
Record: Obviously correct — mechanical, identical change across all 10
helpers. The loop simply continues processing remaining chunks (which is
already the behavior for non-last fields). Reviewed by the original AVX2
implementation author (Stefano Brivio). No public API changes.
Negligible regression risk — marginally more SIMD iterations when `last`
is true, but this is the correct behavior.

===============================================================
## PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: Blame**
Record: `git blame` confirms all buggy `if (last) return b;` lines were
introduced by commit `7400b063969bd` (Stefano Brivio, 2020-03-07) —
"nft_set_pipapo: Introduce AVX2-based lookup implementation", first in
v5.7-rc1. The bug has existed since the original AVX2 pipapo code was
written.

**Step 3.2: Fixes Tag**
Record: No explicit Fixes: tag. The commit body references
`7711f4bb4b36` ("fix range overlap detection") as the commit that
exposed the bug (by changing duplicate comparison from
`sizeof(*dup_key->data)` to `set->klen`). Verified: `7711f4bb4b36` first
appeared in v6.19-rc5, and has been backported to v6.18 stable (as
`704c0258f0d79`).

**Step 3.3: File History and Related Changes**
Record: The critical prerequisite chain is:
1. `416e53e395167` (v6.18-rc1) — Split `nft_pipapo_avx2_lookup()` into
   `pipapo_get_avx2()` helper + thin wrapper. Created the shared AVX2
   lookup function.
2. `84c1da7b38d9a` (v6.18-rc1) — Made control-plane `pipapo_get()`
   dispatch to `pipapo_get_avx2()` when AVX2 is available. Made
   `pipapo_get_avx2()` non-static.
3. `5823699a11cf3` (v6.18-rc1) — Fixed expired-entry retry from full-
   loop restart to `pipapo_refill()` on existing map. This is the commit
   that makes stale bits in the map a real problem — because now
   `pipapo_refill()` operates on the existing `res` map which has stale
   bits left by the early-returning helpers.

**Step 3.4: Author Context**
Record: Florian Westphal is a netfilter maintainer. Stefano Brivio
(reviewer) is the original pipapo AVX2 author. Pablo Neira Ayuso (co-
signer) is the netfilter subsystem maintainer.

**Step 3.5: Dependencies**
Record: The fix itself is self-contained and applies cleanly. However,
the bug is only reachable in trees that contain all three prerequisites
(`416e53e395167`, `84c1da7b38d9a`, `5823699a11cf3`). Verified via `git
merge-base --is-ancestor`:
- v5.15: none present (exit code 1)
- v6.1: none present (exit code 1)
- v6.6: none present (exit code 1)
- v6.12: none present (exit code 1)
- v6.18: all present (exit code 0)
- v6.19: all present (exit code 0)

===============================================================
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: Patch Discussion**
Record: Direct lore.kernel.org fetch blocked by Anubis anti-bot
protection. The Link: tag points to the netfilter-devel discussion.

**Step 4.2: Bug Report**
Record: Bug was found via a new test case (described in the commit
message), not via an external bug report. The test exercises
flush+reload of pipapo sets with multi-field keys.

**Step 4.3: Related Patches**
Record: This is patch 1 of a 2-patch series. Patch 2 adds a regression
selftest (`selftests: netfilter: nft_concat_range.sh`). The code fix is
standalone.

**Step 4.4: Stable Discussion**
Record: Could not search lore stable archives due to access
restrictions. No evidence found of prior stable discussion.

===============================================================
## PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: Functions Modified**
Record: 10 AVX2 lookup helpers: `nft_pipapo_avx2_lookup_{4b_2, 4b_4,
4b_8, 4b_12, 4b_32, 8b_1, 8b_2, 8b_4, 8b_6, 8b_16}`.

**Step 5.2: Callers**
Record: All 10 helpers are called from `pipapo_get_avx2()` via the
`NFT_SET_PIPAPO_AVX2_LOOKUP` macro (lines 1186-1222).
`pipapo_get_avx2()` is called from:
1. **Control plane**: `pipapo_get()` in `nft_set_pipapo.c` (line 534),
   which is called during element insertion/duplicate checking
   (`nft_pipapo_insert()` at lines 1309, 1330), element retrieval
   (`nft_pipapo_get()` at line 605), and deactivation (line 1905).
2. **Data path**: `nft_pipapo_avx2_lookup()` (line 1298), called during
   packet classification.

Both paths are affected when an expired/inactive element is found and
`pipapo_refill()` is invoked on a stale bitmap.

**Step 5.3: Callees**
Record: Each helper calls `nft_pipapo_avx2_refill()` which for
`last==true` returns the first set bit index in the current chunk. The
caller (`pipapo_get_avx2()`) then checks expiry/genmask and may call
`pipapo_refill()` for retry (line 1242).

**Step 5.4: Call Chain**
Record: Control plane: `nf_tables_newsetelem()` → `nft_add_set_elem()` →
`nft_pipapo_insert()` → `pipapo_get()` → `pipapo_get_avx2()` → AVX2
helpers. Data path: packet → `nft_pipapo_avx2_lookup()` →
`pipapo_get_avx2()` → AVX2 helpers. Both are reachable — control plane
from nftables netlink, data path from every packet hitting a pipapo set.

**Step 5.5: Similar Patterns**
Record: `nft_pipapo_avx2_lookup_slow()` has the same `if (last) return
b;` at line 1078 but is NOT affected because its `pipapo_refill()` call
processes the entire map, not per-chunk. All 10 affected helpers have
the identical pattern.

===============================================================
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
===============================================================

**Step 6.1: Bug Existence in Stable Trees**
Record: Verified via `git merge-base --is-ancestor`:
- The early `return b` pattern exists since v5.7 in all stable trees
- BUT the bug is only triggerable after the retry-via-`pipapo_refill()`
  mechanism from `5823699a11cf3` is present
- `5823699a11cf3`, `416e53e395167`, and `84c1da7b38d9a` are NOT in
  v5.15, v6.1, v6.6, or v6.12 (exit code 1)
- All three ARE in v6.18 and v6.19 (exit code 0)
- Confirmed: v6.18.20 and v6.19.10 still contain the buggy `return b;`
  in all 10 helpers
- Confirmed: v6.18.20 and v6.19.10 both contain the `pipapo_refill()`
  retry at line 1242
- Confirmed: v6.18.20 has the `pipapo_get_avx2()` dispatch in
  `pipapo_get()`
- Confirmed: v6.6 has zero references to `pipapo_get_avx2` in
  `nft_set_pipapo.c`

**Step 6.2: Backport Complications**
Record: Clean apply expected for v6.18.y and v6.19.y. The buggy lines
are identical in both trees. Not relevant to v6.12 and older.

**Step 6.3: Related Fixes in Stable**
Record: `7711f4bb4b36` (range overlap detection fix) was backported to
v6.18 stable as `704c0258f0d79`. This backport makes the false-clash
symptom more visible on v6.18. No equivalent of the commit under review
is present in any stable tree.

===============================================================
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: Subsystem Criticality**
Record: [netfilter / nftables] [IMPORTANT — core packet
filtering/firewalling infrastructure used by virtually all Linux
systems]

**Step 7.2: Subsystem Activity**
Record: Actively maintained with frequent correctness fixes. The pipapo
AVX2 implementation has seen several related fixes recently
(5823699a11cf3, 7711f4bb4b36, etc.), indicating this area is under
active maintenance.

===============================================================
## PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: Who Is Affected**
Record: All x86_64 systems with AVX2 (essentially all modern x86 since
Haswell/2013) running kernel v6.18+ that use nftables with concatenated
range sets (pipapo). Affects both:
- **Control plane**: Element insertion/overlap checking fails with false
  clashes
- **Data path**: Packet lookup can return wrong element/verdict when
  expired entries exist in the set

**Step 8.2: Trigger Conditions**
Record:
- Control plane: Load a pipapo set, flush it, reload it → false clash
  reported
- Data path: Any packet hitting a pipapo set where an expired element
  exists and the map spans >1 YMM chunk
- Trigger is realistic for any system that periodically reloads firewall
  rules or uses element timeouts
- Requires no special privileges beyond nftables administration for
  control-plane path

**Step 8.3: Failure Mode Severity**
Record:
- Control plane: False element clashes → nftables set reload fails →
  **firewall update/deployment breaks** → HIGH
- Data path: Wrong element matched → **wrong firewall verdict applied to
  packet** → **CRITICAL** (security-relevant: packets could be
  incorrectly allowed or denied)
- Combined severity: **HIGH**

**Step 8.4: Risk-Benefit Ratio**
Record:
- Benefit: **HIGH** — fixes both control-plane set operations and
  potential data-path incorrect matching
- Risk: **VERY LOW** — 10 identical one-token changes, each replacing
  `return b` with `ret = b`, letting the loop finish naturally. Reviewed
  by original pipapo AVX2 author. No API/ABI changes.
- Ratio: Strongly favors backporting

===============================================================
## PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: Evidence Compilation**

FOR backporting:
- Real, verified correctness bug in netfilter set matching with concrete
  reproducer
- Affects both control-plane (set reload fails) and data-path (wrong
  packet matching — security-relevant)
- Extremely minimal fix: 10 identical one-token changes in a single file
- Reviewed by original pipapo AVX2 implementation author (Stefano
  Brivio)
- Applied through proper netfilter maintainer chain (Florian Westphal →
  Pablo Neira Ayuso)
- Bug has existed since v5.7 but only reachable after v6.18-rc1
  refactoring
- Both v6.18.20 and v6.19.10 confirmed to still contain the buggy
  pattern
- Netfilter is critical security/networking infrastructure

AGAINST backporting:
- Only relevant to v6.18.y and v6.19.y (not older stable trees)
- No explicit Fixes: or Cc: stable tags (expected for manual review)

UNRESOLVED:
- Could not fetch lore.kernel.org discussion due to anti-bot protection
- Could not verify whether reviewer suggested Cc: stable in discussion

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivial change, reviewed by
   original author, companion selftest exists
2. Fixes a real bug? **YES** — false element clashes on set reload,
   potential wrong packet matching
3. Important issue? **YES** — breaks firewall management, potentially
   wrong packet filtering (security)
4. Small and contained? **YES** — 10 lines changed in 1 file, all
   identical
5. No new features or APIs? **YES** — pure bug fix
6. Can apply to stable? **YES** — clean apply to v6.18.y and v6.19.y
   (not relevant to older trees)

**Step 9.3: Exception Categories**
Record: Not applicable — standard bug fix, not an exception category.

**Step 9.4: Decision**
This is a clear, surgical fix for a serious correctness bug in
netfilter's AVX2 pipapo matching. The bug causes incorrect element
matching that can break firewall rule reload operations (false clashes)
and potentially cause wrong data-path packet classification (security-
relevant). The fix is minimal (10 identical one-token changes), reviewed
by the original code author, and carries virtually no regression risk.
It should be backported to v6.18.y and v6.19.y stable trees, which are
the only active stable branches containing the prerequisite code that
makes this bug reachable.

## Verification

- [Phase 1] Parsed tags: Reviewed-by from Stefano Brivio (original
  pipapo AVX2 author), Signed-off-by from Pablo Neira Ayuso (netfilter
  maintainer), Link to lore discussion
- [Phase 2] Diff analysis: 10 identical changes `return b;` → `ret = b;`
  across 10 AVX2 lookup functions in single file `nft_set_pipapo_avx2.c`
- [Phase 3] `git blame -L 240,260`: buggy `return b` introduced by
  `7400b063969bd` (Stefano Brivio, v5.7-rc1)
- [Phase 3] `git describe --contains 7400b063969bd`: confirmed v5.7-rc1
- [Phase 3] `git log --oneline -30 --
  net/netfilter/nft_set_pipapo_avx2.c`: verified complete file history
  including all prerequisite commits
- [Phase 3] `git show 84c1da7b38d9a`: confirmed it creates
  `pipapo_get()` dispatcher calling `pipapo_get_avx2()` from control
  plane, and renames old `pipapo_get()` to `pipapo_get_slow()`
- [Phase 3] `git show 5823699a11cf3`: confirmed it changes expired-entry
  retry from full-loop restart to `pipapo_refill()` on existing map
- [Phase 3] `git show 416e53e395167`: confirmed it splits
  `nft_pipapo_avx2_lookup()` into `pipapo_get_avx2()` helper
- [Phase 3] `git describe --contains`: 84c1da7b38d9a → v6.18-rc1,
  5823699a11cf3 → v6.18-rc1, 7711f4bb4b36 → v6.19-rc5
- [Phase 3] `git merge-base --is-ancestor 84c1da7b38d9a v6.6`: exit code
  1 (NOT present)
- [Phase 3] `git merge-base --is-ancestor 84c1da7b38d9a v6.12`: exit
  code 1 (NOT present)
- [Phase 3] `git merge-base --is-ancestor 84c1da7b38d9a v6.18`: exit
  code 0 (present)
- [Phase 3] `git merge-base --is-ancestor 84c1da7b38d9a v6.19`: exit
  code 0 (present)
- [Phase 3] `git merge-base --is-ancestor 416e53e395167 v6.18`: exit
  code 0 (present)
- [Phase 3] `git merge-base --is-ancestor 5823699a11cf3 v6.18`: exit
  code 0 (present)
- [Phase 3] Same two commits also verified present in v6.19
- [Phase 4] UNVERIFIED: lore.kernel.org blocked by Anubis anti-bot
  protection
- [Phase 5] Grep `pipapo_get_avx2` in `net/netfilter/`: confirmed called
  from `pipapo_get()` (control plane, line 534 of nft_set_pipapo.c) and
  `nft_pipapo_avx2_lookup()` (datapath, line 1298 of avx2 file)
- [Phase 5] Read lines 1228-1261: confirmed retry path with
  `pipapo_refill()` at line 1242, `goto next_match` at line 1244
- [Phase 5] Grep `pipapo_get` in `nft_set_pipapo.c`: confirmed call
  sites at insert path (lines 1309, 1330), get path (line 605),
  deactivation (line 1905)
- [Phase 6] `git show v6.19.10:net/netfilter/nft_set_pipapo_avx2.c |
  grep 'return b;'`: 11 matches confirm buggy pattern still present
- [Phase 6] `git show v6.18.20:net/netfilter/nft_set_pipapo_avx2.c |
  grep 'return b;'`: 11 matches confirm buggy pattern still present
- [Phase 6] `git show v6.18.20:net/netfilter/nft_set_pipapo_avx2.c |
  grep pipapo_refill`: confirmed retry mechanism at line 1242
- [Phase 6] `git show v6.18.20:net/netfilter/nft_set_pipapo.c | grep
  pipapo_get_avx2`: confirmed control-plane dispatch present
- [Phase 6] `git show v6.6:net/netfilter/nft_set_pipapo.c | grep -c
  pipapo_get_avx2`: 0 matches — NOT present in v6.6
- [Phase 6] `git log v6.18..v6.18.20 --
  net/netfilter/nft_set_pipapo*.c`: confirmed no equivalent fix already
  backported
- [Phase 8] Failure mode: control-plane false clashes (HIGH), data-path
  wrong matching (CRITICAL for security), combined severity HIGH

**YES**

 net/netfilter/nft_set_pipapo_avx2.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/net/netfilter/nft_set_pipapo_avx2.c b/net/netfilter/nft_set_pipapo_avx2.c
index 7ff90325c97fa..6395982e4d95c 100644
--- a/net/netfilter/nft_set_pipapo_avx2.c
+++ b/net/netfilter/nft_set_pipapo_avx2.c
@@ -242,7 +242,7 @@ static int nft_pipapo_avx2_lookup_4b_2(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -319,7 +319,7 @@ static int nft_pipapo_avx2_lookup_4b_4(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -414,7 +414,7 @@ static int nft_pipapo_avx2_lookup_4b_8(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -505,7 +505,7 @@ static int nft_pipapo_avx2_lookup_4b_12(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -641,7 +641,7 @@ static int nft_pipapo_avx2_lookup_4b_32(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -699,7 +699,7 @@ static int nft_pipapo_avx2_lookup_8b_1(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -764,7 +764,7 @@ static int nft_pipapo_avx2_lookup_8b_2(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -839,7 +839,7 @@ static int nft_pipapo_avx2_lookup_8b_4(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -925,7 +925,7 @@ static int nft_pipapo_avx2_lookup_8b_6(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
@@ -1019,7 +1019,7 @@ static int nft_pipapo_avx2_lookup_8b_16(unsigned long *map, unsigned long *fill,
 
 		b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
 		if (last)
-			return b;
+			ret = b;
 
 		if (unlikely(ret == -1))
 			ret = b / XSAVE_YMM_SIZE;
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] ASoC: SOF: topology: reject invalid vendor array size in token parser

[Sasha Levin]

From: Cássio Gabriel <cassiogabrielcontato@gmail.com>

[ Upstream commit 215e5fe75881a7e2425df04aeeed47a903d5cd5d ]

sof_parse_token_sets() accepts array->size values that can be invalid
for a vendor tuple array header. In particular, a zero size does not
advance the parser state and can lead to non-progress parsing on
malformed topology data.

Validate array->size against the minimum header size and reject values
smaller than sizeof(*array) before parsing. This preserves behavior for
valid topologies and hardens malformed-input handling.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260319-sof-topology-array-size-fix-v1-1-f9191b16b1b7@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis.

===============================================================
## PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1:** Record: [ASoC: SOF: topology] [reject] [reject invalid
vendor array size in token parser to prevent non-progress parsing]

**Step 1.2:** Record: Tags present:
- Signed-off-by: Cássio Gabriel (author)
- Acked-by: Peter Ujfalusi (confirmed listed SOF maintainer in
  MAINTAINERS)
- Link: patch.msgid.link URL
- Signed-off-by: Mark Brown (ASoC maintainer, merged the patch)
- No Fixes:, Reported-by:, Tested-by:, Cc: stable tags (expected for
  manual review candidates)

**Step 1.3:** Record: Bug: `sof_parse_token_sets()` accepts
`array->size` values that are invalid — specifically, a zero size does
not advance parser state. Symptom: non-progress parsing (infinite loop)
on malformed topology data. Root cause: the validation only checked
`asize < 0`, which cannot catch zero or small positive values.

**Step 1.4:** Record: Yes, this is a real bug fix despite "hardens"
language. The commit fixes a concrete infinite loop scenario where
`asize == 0` causes the parser while-loop to never terminate.

===============================================================
## PHASE 2: DIFF ANALYSIS
===============================================================

**Step 2.1:** Record: 1 file changed (`sound/soc/sof/topology.c`), 1
line modified. Function modified: `sof_parse_token_sets()`.
Classification: single-file, single-line surgical fix.

**Step 2.2:** Record: Before: `if (asize < 0)` — only rejects negative
values. After: `if (asize < sizeof(*array))` — rejects any value smaller
than the vendor array header size. The FIXME comment ("A zero-size array
makes no sense") was already documenting this known deficiency.

**Step 2.3:** Record: Bug category: logic/infinite loop. The while loop
at line 735 uses `array_size -= asize` (line 746) and advances the
pointer via `array = (u8*)array + asize` (line 784). When `asize == 0`:
1. `array_size -= 0` — no change, stays positive
2. `array = array + 0` — pointer doesn't advance
3. The while condition `array_size > 0 && total < count *
   token_instance_num` remains true
4. Result: **infinite loop / soft lockup**

**Step 2.4:** Record: The fix is obviously correct. `struct
snd_soc_tplg_vendor_array` has three `__le32` header fields (`size`,
`type`, `num_elems`) = 12 bytes minimum, plus a flex array union. Any
valid array must be at least `sizeof(*array)` bytes. Note on type
promotion: `asize` is `int`, `sizeof(*)` is `size_t`. A negative `asize`
promotes to a very large unsigned value, so `asize < sizeof(*)` would be
false — but negative `asize` is still caught by the subsequent
`array_size -= asize; if (array_size < 0)` check at line 747, so no
regression.

===============================================================
## PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1:** Record: `git blame` confirms the buggy `if (asize < 0)`
check was introduced in commit `311ce4fe7637d9` ("ASoC: SOF: Add support
for loading topologies") by Liam Girdwood, 2019-04-12. `git describe
--contains` shows this is `v5.2-rc1`. The bug has been present since
**v5.2** — all active stable trees contain it.

**Step 3.2:** Record: No Fixes: tag present. The buggy commit is
`311ce4fe7637d9`.

**Step 3.3:** Record: `git log --oneline -20` shows active development
but no related prerequisite or duplicate fix for this specific issue.

**Step 3.4:** Record: Peter Ujfalusi (Acked-by) is a listed maintainer
for SOF in MAINTAINERS. Mark Brown signed off as ASoC subsystem
maintainer. Strong maintainer endorsement.

**Step 3.5:** Record: No dependencies. The fix changes one condition in
an existing function with no new types, helpers, or APIs needed.

===============================================================
## PHASE 4: MAILING LIST RESEARCH
===============================================================

Record: The patch.msgid.link and lore.kernel.org URLs are blocked by
Anubis bot protection in this environment. However, the patch was Acked
by a listed SOF maintainer (Peter Ujfalusi) and merged by the ASoC
maintainer (Mark Brown), providing strong review signal.

===============================================================
## PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1:** Record: Modified function: `sof_parse_token_sets()`

**Step 5.2:** Record: `sof_parse_token_sets()` is called from:
1. `sof_parse_tokens()` — a wrapper called from ~9 locations throughout
   topology.c (control load, widget parsing, DAI load, link load,
   DSPless widget paths)
2. `sof_parse_pin_binding()` — direct call for pin binding token parsing

This is a heavily-used core parsing function in the SOF topology loader.

**Step 5.3-5.4:** Record: The call chain is: `sof_pcm_probe()` →
`snd_sof_load_topology()` → `snd_soc_tplg_component_load()` → SOF
callbacks (widget_ready, dai_load, link_load, control_load) →
`sof_parse_tokens()` → `sof_parse_token_sets()`. This is triggered
during SOF audio component probe when topology firmware blobs are
loaded.

**Step 5.5:** Record: The **same weak check** (`if (asize < 0)`) exists
in `sof_copy_tuples()` at line 544, with identical loop structure and
pointer advancement at line 610. This sibling function has the same
vulnerability but is NOT fixed by this commit. This means the patch is
not a complete fix across all SOF topology parsing paths, but it does
fix the specific path through `sof_parse_token_sets()`.

===============================================================
## PHASE 6: STABLE TREE ANALYSIS
===============================================================

**Step 6.1:** Record: The buggy code was introduced in v5.2. All active
stable trees (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y) contain this
vulnerable code.

**Step 6.2:** Record: Expected clean or trivial backport — the `if
(asize < 0)` line with the FIXME comment hasn't changed since
introduction.

**Step 6.3:** Record: No duplicate or alternative fix found for this
exact issue in git history.

===============================================================
## PHASE 7: SUBSYSTEM CONTEXT
===============================================================

**Step 7.1:** Record: Subsystem: sound/soc/sof (Sound Open Firmware).
Criticality: IMPORTANT — SOF is used on most modern Intel laptops for
audio hardware.

**Step 7.2:** Record: Active subsystem with regular commits.

===============================================================
## PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1:** Record: Affected users: SOF audio hardware users (very
common on Intel-based laptops/desktops).

**Step 8.2:** Record: Trigger: malformed/corrupt SOF topology blob with
`array->size == 0` (or < header size). Topology files are loaded from
firmware path during driver probe. Trigger requires corrupt or
maliciously crafted topology data — uncommon in normal operation but
possible from disk corruption or adversarial input.

**Step 8.3:** Record: Failure mode: infinite loop in kernel context →
soft lockup → system hang during audio driver probe. Severity: HIGH
(system hang, unavailability).

**Step 8.4:** Record:
- **Benefit:** Prevents a real infinite loop / system hang. The FIXME
  comment proves the developer knew this was broken. Low-medium benefit
  (real hang, but only on malformed input).
- **Risk:** Very low. Single condition change; valid topologies always
  have `asize >= sizeof(*array)`. No regression for valid data. Acked by
  subsystem maintainer.
- **Ratio:** Favorable — high confidence in correctness, near-zero
  regression risk, fixes real hang.

===============================================================
## PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: Evidence compilation**

FOR backporting:
- Fixes a concrete infinite loop (system hang) — the FIXME comment
  proves this was a known deficiency
- Single-line, obviously correct fix
- Acked by listed SOF subsystem maintainer (Peter Ujfalusi)
- Merged by ASoC maintainer (Mark Brown)
- Bug present since v5.2 — exists in all active stable trees
- Near-zero regression risk for valid topologies
- `sof_parse_token_sets()` is called from ~10 locations — well-used code
  path

AGAINST backporting:
- Trigger requires malformed topology data (not normal operation)
- No user/syzbot crash report — found by code inspection
- The parallel `sof_copy_tuples()` function retains the same weak check
  (incomplete coverage)
- SOF is important but not core kernel — affects hardware-specific users

**Step 9.2: Stable rules checklist**
1. Obviously correct and tested? **YES** — maintainer acked, trivially
   verifiable from code
2. Fixes a real bug? **YES** — infinite loop on malformed input
   (acknowledged by FIXME comment)
3. Important issue? **YES** — system hang (soft lockup), HIGH severity
4. Small and contained? **YES** — 1 line changed, 1 function, 1 file
5. No new features or APIs? **YES**
6. Can apply to stable trees? **YES** — identical code in all stable
   trees

**Step 9.3:** Record: No exception category — standard bug fix.

**Step 9.4: Decision**

This commit fixes a real, documented infinite loop bug (the original
code even had a FIXME acknowledging the problem). The fix is a single-
line minimum-size validation, acked by the subsystem maintainer, with
near-zero regression risk. While the trigger requires malformed topology
data, a system hang is a serious failure mode — stable kernels should
handle invalid input gracefully without hanging. The incomplete coverage
of the sibling function `sof_copy_tuples()` does not diminish the value
of fixing this specific path. The fix meets all stable kernel criteria.

## Verification

- [Phase 1] Parsed all tags from supplied commit message: Acked-by Peter
  Ujfalusi, Signed-off-by Mark Brown, Link to patch.msgid.link
- [Phase 1] Verified Peter Ujfalusi is listed as maintainer in
  MAINTAINERS under "SOUND - SOUND OPEN FIRMWARE (SOF) DRIVERS"
- [Phase 2] Read `sof_parse_token_sets()` (lines 724-793): confirmed
  while loop at line 735, `array_size -= asize` at line 746, pointer
  advance `(u8*)array + asize` at line 784 — `asize == 0` causes
  infinite loop
- [Phase 2] Verified `struct snd_soc_tplg_vendor_array` in
  `include/uapi/sound/asoc.h` (line 220): three `__le32` fields (`size`,
  `type`, `num_elems`) + flex array union — `sizeof(*array)` is the
  correct minimum header size
- [Phase 2] Verified type safety: `int asize` compared against `size_t
  sizeof(*)` — negative values promote to large unsigned (caught by
  subsequent `array_size < 0` check at line 747)
- [Phase 3] git blame: buggy `if (asize < 0)` line attributed to commit
  `311ce4fe7637d9` (Liam Girdwood, 2019-04-12)
- [Phase 3] git describe: `311ce4fe7637d9` first appeared in `v5.2-rc1`
  — bug present in all active stable trees
- [Phase 3] git log -20: no prerequisites or duplicate fixes found
- [Phase 5] grep callers: `sof_parse_token_sets()` called from
  `sof_parse_tokens()` (~9 call sites) and `sof_parse_pin_binding()` (1
  call site)
- [Phase 5] grep: found same weak `if (asize < 0)` check in sibling
  `sof_copy_tuples()` at line 544, with identical loop/advance pattern
  at line 610 — NOT fixed by this commit
- [Phase 6] Buggy code unchanged since v5.2 — clean backport expected to
  all active stable trees
- [Phase 8] Failure mode: infinite loop in kernel context → soft
  lockup/system hang during topology load. Severity: HIGH
- UNVERIFIED: Lore discussion content (blocked by Anubis protection)
- UNVERIFIED: Whether unprivileged users can trigger topology loading on
  specific distributions
- UNVERIFIED: Exact runtime `sizeof(struct snd_soc_tplg_vendor_array)`
  (struct is `__packed` with flex array — compile-time verification not
  performed)

**YES**

 sound/soc/sof/topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index 9bf8ab610a7ea..8880ac5d8d6ff 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -736,7 +736,7 @@ static int sof_parse_token_sets(struct snd_soc_component *scomp,
 		asize = le32_to_cpu(array->size);
 
 		/* validate asize */
-		if (asize < 0) { /* FIXME: A zero-size array makes no sense */
+		if (asize < sizeof(*array)) {
 			dev_err(scomp->dev, "error: invalid array size 0x%x\n",
 				asize);
 			return -EINVAL;
-- 
2.53.0

[PATCH AUTOSEL 6.19] ALSA: hda/realtek - Fixed Speaker Mute LED for HP EliteBoard G1a platform

[Sasha Levin]

From: Kailang Yang <kailang@realtek.com>

[ Upstream commit d3be95efc6a1e03230ef646b498050152efe2888 ]

On the HP EliteBoard G1a platform (models without a headphone jack).
the speaker mute LED failed to function. The Sysfs ctl-led info showed
empty values because the standard LED registration couldn't correctly
bind to the master switch.
Adding this patch will fix and enable the speaker mute LED feature.

Tested-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Kailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/279e929e884849df84687dbd67f20037@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
Record: [ALSA: hda/realtek] [Fixed] [Speaker mute LED not working on HP
EliteBoard G1a, models without headphone jack]

### Step 1.2: Tags
- **Tested-by**: Chris Chiu <chris.chiu@canonical.com> — Canonical
  developer verified the fix on real hardware
- **Signed-off-by**: Kailang Yang <kailang@realtek.com> — author is from
  Realtek, the codec vendor
- **Link**:
  https://lore.kernel.org/279e929e884849df84687dbd67f20037@realtek.com
- **Signed-off-by**: Takashi Iwai <tiwai@suse.de> — ALSA subsystem
  maintainer accepted it
- No Fixes:, Reported-by:, Cc: stable tags (expected for this review
  pipeline)

Record: Tested-by from Canonical, author is Realtek vendor engineer,
accepted by ALSA maintainer. No Fixes: tag.

### Step 1.3: Commit Body
Record: Bug: On HP EliteBoard G1a (models without headphone jack), the
speaker mute LED fails to function. Sysfs `ctl-led` info shows empty
values because the standard LED registration couldn't bind to the master
switch. Symptom: Non-functional mute LED. Root cause: The LED classdev
registration mechanism doesn't work properly when there is no HP pin on
the platform.

### Step 1.4: Hidden Bug Fix
Record: Not hidden — explicitly labeled as a "Fixed" in the subject.
This is a straightforward hardware quirk fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 — `sound/hda/codecs/realtek/alc269.c`
- **Lines**: ~20 added, ~1 removed (net +19)
- **Functions**: New `alc245_hp_spk_mute_led_update()`; modified
  `alc245_tas2781_i2c_hp_fixup_muteled()`
- **Scope**: Single-file, surgical fix

Record: 1 file, ~20 lines added, 1 function modified, 1 small helper
added. Single-file surgical fix.

### Step 2.2: Code Flow Change

**New function `alc245_hp_spk_mute_led_update()`**: A vmaster hook
callback that writes COEF register 0x0b with mask 0x0c, setting 0x08
when `enabled=1` and 0x04 when `enabled=0`.

**Modified `alc245_tas2781_i2c_hp_fixup_muteled()`**:
- **Before**: Always called `alc245_fixup_hp_mute_led_coefbit()` after
  TAS2781 fixup, which registers a LED classdev via
  `snd_hda_gen_add_mute_led_cdev()`.
- **After**: Reads `alc_get_hp_pin(spec)` at function entry. If no HP
  pin: sets `vmaster_mute.hook` to the new direct-write function, sets
  `vmaster_mute_led = 1`, syncs LED state during `HDA_FIXUP_ACT_INIT`.
  Only calls `alc245_fixup_hp_mute_led_coefbit()` if `hp_pin` is non-
  zero.

Record: Before: always uses LED classdev path. After: uses direct
vmaster hook when no HP pin, LED classdev when HP pin present.

### Step 2.3: Bug Mechanism
Record: [Hardware workaround]. The standard LED classdev registration
via `snd_hda_gen_add_mute_led_cdev()` cannot bind properly to the master
switch on platforms without a headphone pin. The fix bypasses the
classdev and uses the `vmaster_mute.hook` mechanism for direct register
control.

### Step 2.4: Fix Quality — Polarity and Probe Ordering Analysis

**Polarity concern**: The existing `alc245_fixup_hp_mute_led_coefbit`
path uses the LED classdev, which turns LED ON (writes 0x08) when audio
is MUTED. The new vmaster hook path writes 0x08 when `enabled=1` (audio
NOT muted). This is an apparent polarity inversion. However, the
`vmaster_mute.hook` convention (seen in analog.c, conexant.c,
senarytech.c) passes `enabled=1` for unmuted, `enabled=0` for muted — so
the new function maps unmuted → 0x08 (LED on), muted → 0x04 (LED off).
This is opposite to the mute-LED convention but may be intentionally
correct for this specific hardware platform. The Tested-by from Chris
Chiu confirms correct behavior on the target hardware.

**Probe ordering concern**: `alc_get_hp_pin(spec)` reads
`spec->gen.autocfg.hp_pins[0]`, which is populated by
`alc269_parse_auto_config()`. During `HDA_FIXUP_ACT_PRE_PROBE` (line
8595), this function runs BEFORE `alc269_parse_auto_config()` (line
8603), meaning `hp_pins[0]` is always 0 at PRE_PROBE time. This means
`!hp_pin` is ALWAYS true during PRE_PROBE, so the vmaster hook path
activates for ALL platforms using this fixup, not just no-HP models.
However, during INIT (which runs after autocfg parsing), `hp_pin`
correctly reflects the actual hardware. The `if (!hp_pin)` check in the
INIT case correctly gates the LED sync.

Record: Two technical concerns: (1) apparent LED polarity inversion vs
standard convention, (2) probe ordering means hp_pin check is always
true during PRE_PROBE. Both are mitigated by Tested-by on real hardware,
vendor authorship, and maintainer acceptance.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
`alc245_tas2781_i2c_hp_fixup_muteled` was introduced by commit
`9afbbf4903228c` (Kailang Yang, 2025-11-20, "ALSA: hda/realtek - Enable
Mute LED and Tas2781 for HP platform"). The commit first appeared in
v6.19-rc1. The ZBook 8 G2a entries (0x8f40, 0x8f41, 0x8f42, 0x8f62) were
also added by the same commit.

Record: Function introduced in 9afbbf4903228c, v6.19-rc1 (2025-11-20),
by same author.

### Step 3.2: Fixes Tag
No Fixes: tag present. If one existed, it would logically point to
`9afbbf4903228c`.

Record: N/A — no Fixes tag.

### Step 3.3: File History
Recent `alc269.c` history shows very active development with many quirk
additions and LED fixes. No intermediate fixes for this specific
function were found.

Record: Standalone fix, no visible prerequisites beyond 9afbbf4903228c.

### Step 3.4: Author
Kailang Yang (Realtek) is the codec vendor engineer and a frequent
contributor to this driver. He authored the original function
(9afbbf4903228c), the ZBook LED commit (500372aeb556a), and several
other Realtek fixes. Takashi Iwai (ALSA maintainer) accepted the patch.

Record: Author is the Realtek codec vendor engineer — maximum authority
for codec-specific behavior.

### Step 3.5: Dependencies
- Depends on `alc245_tas2781_i2c_hp_fixup_muteled()` from 9afbbf4903228c
- Depends on `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED` and associated
  SND_PCI_QUIRK entries
- All present in v6.19, absent from v6.18 and older

Record: Dependencies all exist in 6.19.y. Cannot apply to older stable
trees.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Lore
Lore link in the commit points to internal Realtek email;
lore.kernel.org was blocked by Anubis bot protection. Could not access
patch discussion.

Record: UNVERIFIED — could not access lore discussion.

### Step 4.2: Bug Report
**Ubuntu Launchpad Bug #2136846** ("Fix speaker mute and mic mute leds
on a HP EliteBoard G1a") was found and fetched. Key findings:
- Filed by Chris Chiu (the Tested-by person) on 2025-12-19
- Platform: HP NexusX (SSID 0x103c:0x8e8a) using Realtek ALC3315+TAS2783
- The initial upstream fix (fd324768eb2c "ALSA: hda/tas2781: Add new
  quirk for HP new project") was insufficient — **Comment #3** from
  Chris Chiu: "Verified... the mic-mute led works but the mute led does
  not."
- The candidate commit is the follow-up to address the remaining speaker
  mute LED issue
- Ubuntu tracked this as an OEM-priority bug and it was marked "Fix
  Released" for linux-oem-6.17 and later confirmed "6.19 has it"

Record: Real-world bug confirmed by Ubuntu Launchpad #2136846. Mic-mute
LED worked after first fix, speaker mute LED still broken — this commit
is the specific follow-up fix.

### Step 4.3-4.4: Related Patches and Stable History
No direct stable-mailing-list discussion found. The Launchpad bug shows
Ubuntu already backported the earlier fix to linux-oem-6.17.

Record: Ubuntu already backported related fixes to their OEM kernel.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
- `alc245_hp_spk_mute_led_update()` (new) — vmaster hook for direct LED
  control
- `alc245_tas2781_i2c_hp_fixup_muteled()` (modified) — fixup function

### Step 5.2: Callers
`alc245_tas2781_i2c_hp_fixup_muteled` is called via the fixup table
entry `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED`, triggered by SND_PCI_QUIRK
entries for:
- HP NexusX (0x103c, 0x8e8a)
- HP ZBook 8 G2a 14/16/14W/16W (0x103c, 0x8f40/8f41/8f42/8f62)

The new hook function is called by the generic vmaster framework during
Master Playback Switch changes.

Record: Called from quirk table for 5 specific HP platform SSIDs. Well-
defined scope.

### Step 5.3: Callees
- `alc_update_coef_idx()` — standard codec coefficient register update,
  used 64+ times in this file
- `alc_get_hp_pin()` — reads `spec->gen.autocfg.hp_pins[0]` or
  line_out_pins[0] if type is HP

### Step 5.4: Call Chain
PCI SSID match → `alc245_tas2781_i2c_hp_fixup_muteled` (PRE_PROBE/INIT)
→ `vmaster_mute.hook` set → generic HDA build connects hook to Master
Playback Switch → hook fires on mute state change. Reachable from
userspace ALSA mixer controls and platform hotkeys.

Record: Path reachable from userspace mixer and hardware mute button.

### Step 5.5: Similar Patterns
The `vmaster_mute.hook` mechanism is used in 4+ other codec drivers
(analog, conexant, senarytech, ca0132). The pattern of direct COEF
register writes for LED control is standard in the Realtek driver.

Record: Uses well-established patterns from multiple codec drivers.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: Code Existence in Stable Trees
- **v6.19**: `alc245_tas2781_i2c_hp_fixup_muteled` EXISTS (verified via
  `git show v6.19:...`)
- **v6.18**: DOES NOT EXIST (verified, returns 0 matches)
- **v6.12**: DOES NOT EXIST (verified, returns 0 matches)
- `9afbbf4903228c` is ancestor of v6.19 but NOT ancestor of v6.18

Record: **Only 6.19.y contains the buggy code.** Not applicable to
6.18.y, 6.12.y, 6.6.y, 6.1.y, or any older LTS trees.

### Step 6.2: Backport Complications
For 6.19.y: The function body in v6.19 matches the pre-patch context of
the diff. Should apply cleanly.

Record: Clean apply expected for 6.19.y only.

### Step 6.3: Related Fixes in Stable
No related fixes for this specific issue already in stable.

Record: No duplicate fixes.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
- Subsystem: sound/hda/codecs/realtek — HDA audio codec driver
- Criticality: IMPORTANT for affected laptops/workstations (audio is
  user-facing), but driver-specific

Record: IMPORTANT subsystem, driver-specific fix.

### Step 7.2: Subsystem Activity
The file is extremely active with constant quirk additions and LED
fixes. This is routine maintenance for the Realtek codec driver.

Record: Highly active subsystem; mute LED fixes are common and routine.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
HP EliteBoard G1a (NexusX) and potentially HP ZBook 8 G2a users running
6.19.y stable kernels with the `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED`
fixup.

Record: Driver-specific, affects users of specific HP platforms on
6.19.y.

### Step 8.2: Trigger Conditions
The bug triggers on every boot — the mute LED simply never works. 100%
reproducible on affected hardware.

Record: Always triggers on affected hardware. Confirmed reproducible by
Launchpad bug.

### Step 8.3: Failure Mode Severity
Non-functional speaker mute LED. Audio mute/unmute itself works
correctly. This is a LOW severity user experience issue — no crash, no
data corruption, no security impact.

Record: Severity LOW — non-functional LED indicator.

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: LOW-MEDIUM — fixes user-visible hardware feature on
  specific HP platforms. Ubuntu tracked this as OEM-priority.
- **Risk**: LOW — only activates for specific HP platform SSIDs. ~20
  lines, single file. Tested on real hardware. The probe ordering
  concern means the vmaster hook path activates for ALL platforms using
  this fixup (including ZBook), but the worst-case failure mode is wrong
  LED polarity on those platforms (still LOW severity).
- **Ratio**: Favorable — low risk, clear benefit for affected users.

Record: Benefit > Risk. Small, well-tested change with bounded failure
modes.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real user-facing issue confirmed by Ubuntu Launchpad bug
  #2136846
- Hardware quirk/workaround — explicitly allowed in stable rules
- Small, surgical change (~20 lines, single file)
- Author is the Realtek codec vendor engineer (maximum authority)
- Tested-by from Canonical developer (Chris Chiu) on real hardware
- Accepted by ALSA maintainer (Takashi Iwai)
- Uses well-established `vmaster_mute.hook` mechanism (4+ codec drivers)
- Applies cleanly to 6.19.y
- Ubuntu already prioritized the underlying bug as OEM-priority

**AGAINST backporting:**
- Severity is LOW (LED malfunction, not crash/security/corruption)
- Only applicable to 6.19.y (code doesn't exist in older stable trees)
- Probe ordering issue: `alc_get_hp_pin()` always returns 0 during
  PRE_PROBE, meaning the vmaster hook path activates for ALL platforms
  using this fixup, not just no-HP models
- LED polarity in the vmaster hook appears inverted from the standard
  LED classdev convention
- Code is only ~4 months old (introduced in v6.19-rc1)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** Tested-by present, but probe
   ordering question makes it not 100% "obviously correct" from code
   inspection alone. The polarity inversion is either intentional for
   this hardware or a concern. The Tested-by and maintainer acceptance
   provide practical confidence.
2. **Fixes a real bug?** YES — confirmed by Launchpad bug and Tested-by
3. **Important issue?** Borderline — LED malfunction is low severity,
   but it's a real user-visible hardware issue
4. **Small and contained?** YES — ~20 lines, single file
5. **No new features or APIs?** YES — hardware workaround only
6. **Can apply to stable?** YES — to 6.19.y only

### Step 9.3: Exception Categories
This falls squarely into the **hardware quirk/workaround** exception
category. Audio codec quirks for specific platforms are routinely
backported to stable and are explicitly listed as acceptable in stable
rules.

### Step 9.4: Decision
This is a hardware quirk fix for specific HP platforms, authored by the
Realtek codec vendor, tested on real hardware by Canonical, and accepted
by the ALSA maintainer. While there are legitimate technical concerns
about probe ordering (the `alc_get_hp_pin()` check at PRE_PROBE time)
and LED polarity inversion compared to the standard path, the worst-case
failure mode for any regression is wrong LED behavior (LOW severity),
and the fix was verified working on the target hardware. Hardware quirks
are explicitly allowed in stable, and the fix is only applicable to
6.19.y where the prerequisite code exists. The Ubuntu Launchpad bug
confirms this is a real user-facing issue that was tracked as OEM-
priority.

---

## Verification

- [Phase 1] Parsed commit message and tags from provided text: Tested-by
  Chris Chiu (Canonical), SOB from Kailang Yang (Realtek) and Takashi
  Iwai (ALSA maintainer), Link to lore
- [Phase 2] Read `sound/hda/codecs/realtek/alc269.c` lines 3700-3719
  (pre-patch function), lines 1540-1554
  (`alc245_fixup_hp_mute_led_coefbit` showing coef values: idx=0x0b,
  mask=3<<2=0x0c, on=2<<2=0x08, off=1<<2=0x04)
- [Phase 2] Read `sound/hda/codecs/realtek/alc269.c` lines 1481-1491
  (`coef_mute_led_set` → `alc_update_coef_led` using polarity +
  brightness)
- [Phase 2] Read `sound/hda/codecs/realtek/alc269.c` lines 1470-1479
  (`alc_update_coef_led` logic: if polarity, invert; write on/off based
  on boolean)
- [Phase 2] Verified vmaster hook semantics: `sound/core/vmaster.c` line
  515: `master->hook(master->hook_private_data, master->val)` —
  `master->val` for boolean is 1=unmuted, 0=muted
- [Phase 2] Verified `snd_hda_gen_add_mute_led_cdev()` at
  `sound/hda/codecs/generic.c` lines 3952-3971: sets
  `vmaster_mute_led=1`, checks `if (spec->vmaster_mute.hook)` and prints
  error if already present
- [Phase 2] Confirmed polarity: new hook writes 0x08 when enabled=1
  (unmuted), 0x04 when enabled=0 (muted) — opposite to LED classdev
  convention where brightness=1 (LED on) means muted
- [Phase 2] Verified probe ordering: `alc269.c` line 8595
  (`snd_hda_apply_fixup PRE_PROBE`) runs BEFORE line 8603
  (`alc269_parse_auto_config`), so autocfg.hp_pins is zero during
  PRE_PROBE
- [Phase 2] Verified `alc_get_hp_pin()` at `realtek.c` lines 506-513:
  reads from `spec->gen.autocfg.hp_pins[0]` and `line_out_pins[0]`, both
  empty during PRE_PROBE
- [Phase 2] Cross-checked with existing vmaster hooks:
  `ad_vmaster_eapd_hook` (analog.c:131) and `senary_auto_vmaster_hook`
  (senarytech.c:112) both use `enabled=1` → active, confirming
  convention
- [Phase 3] `git blame -L 3703,3719`: confirmed all lines from
  `9afbbf4903228c` (Kailang Yang, 2025-11-20)
- [Phase 3] `git show 9afbbf4903228c`: confirmed subject "Enable Mute
  LED and Tas2781 for HP platform", 56 lines added, 10 removed
- [Phase 3] `git blame -L 7155,7162`: confirmed ZBook entries
  (0x8f40-0x8f62) also from `9afbbf4903228c`, NexusX also from same
  commit
- [Phase 3] `git log --author='Kailang Yang' -15`: confirmed frequent
  contributor with related commits
- [Phase 4] Fetched Ubuntu Launchpad Bug #2136846: confirmed real bug,
  NexusX platform, comment #3 "mic-mute led works but the mute led does
  not" after initial upstream fix
- [Phase 5] Grep `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED`: found 5
  SND_PCI_QUIRK entries and fixup table definition
- [Phase 5] Grep `vmaster_mute.hook`: confirmed usage in analog.c,
  conexant.c, senarytech.c — well-established pattern
- [Phase 6] `git merge-base --is-ancestor 9afbbf4903228c v6.19` → YES
- [Phase 6] `git merge-base --is-ancestor 9afbbf4903228c v6.18` → NOT
  ancestor
- [Phase 6] `git show v6.19:sound/hda/codecs/realtek/alc269.c | grep
  alc245_tas2781_i2c_hp_fixup_muteled` → found (exists in v6.19)
- [Phase 6] `git show v6.18:...` and `v6.12:...` → 0 matches (does not
  exist in older trees)
- [Phase 6] Fixup table entry confirmed: `.type = HDA_FIXUP_FUNC,
  .v.func = alc245_tas2781_i2c_hp_fixup_muteled` — no chaining to other
  fixups
- UNVERIFIED: Could not access lore.kernel.org discussion due to Anubis
  bot protection
- UNVERIFIED: Whether all ZBook 8 G2a models actually have headphone
  jacks (if they don't, the probe ordering concern is moot)
- UNVERIFIED: Whether the LED polarity inversion is intentional for this
  hardware family or a latent bug (Tested-by and maintainer acceptance
  suggest intentional, but not confirmed)

**YES**

 sound/hda/codecs/realtek/alc269.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 1054191d56fa1..0c710daa945ec 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -3699,22 +3699,42 @@ static void alc245_tas2781_spi_hp_fixup_muteled(struct hda_codec *codec,
 	alc_fixup_hp_gpio_led(codec, action, 0x04, 0x0);
 	alc285_fixup_hp_coef_micmute_led(codec, fix, action);
 }
+
+static void alc245_hp_spk_mute_led_update(void *private_data, int enabled)
+{
+	struct hda_codec *codec = private_data;
+	unsigned int val;
+
+	val = enabled ? 0x08 : 0x04; /* 0x08 led on, 0x04 led off */
+	alc_update_coef_idx(codec, 0x0b, 0x0c, val);
+}
+
 /* JD2: mute led GPIO3: micmute led */
 static void alc245_tas2781_i2c_hp_fixup_muteled(struct hda_codec *codec,
 					  const struct hda_fixup *fix, int action)
 {
 	struct alc_spec *spec = codec->spec;
+	hda_nid_t hp_pin = alc_get_hp_pin(spec);
 	static const hda_nid_t conn[] = { 0x02 };
 
 	switch (action) {
 	case HDA_FIXUP_ACT_PRE_PROBE:
+		if (!hp_pin) {
+			spec->gen.vmaster_mute.hook = alc245_hp_spk_mute_led_update;
+			spec->gen.vmaster_mute_led = 1;
+		}
 		spec->gen.auto_mute_via_amp = 1;
 		snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn), conn);
 		break;
+	case HDA_FIXUP_ACT_INIT:
+		if (!hp_pin)
+			alc245_hp_spk_mute_led_update(codec, !spec->gen.master_mute);
+		break;
 	}
 
 	tas2781_fixup_txnw_i2c(codec, fix, action);
-	alc245_fixup_hp_mute_led_coefbit(codec, fix, action);
+	if (hp_pin)
+		alc245_fixup_hp_mute_led_coefbit(codec, fix, action);
 	alc285_fixup_hp_coef_micmute_led(codec, fix, action);
 }
 /*
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] netfilter: ctnetlink: ensure safe access to master conntrack

[Sasha Levin]

From: Pablo Neira Ayuso <pablo@netfilter.org>

[ Upstream commit bffcaad9afdfe45d7fc777397d3b83c1e3ebffe5 ]

Holding reference on the expectation is not sufficient, the master
conntrack object can just go away, making exp->master invalid.

To access exp->master safely:

- Grab the nf_conntrack_expect_lock, this gets serialized with
  clean_from_lists() which also holds this lock when the master
  conntrack goes away.

- Hold reference on master conntrack via nf_conntrack_find_get().
  Not so easy since the master tuple to look up for the master conntrack
  is not available in the existing problematic paths.

This patch goes for extending the nf_conntrack_expect_lock section
to address this issue for simplicity, in the cases that are described
below this is just slightly extending the lock section.

The add expectation command already holds a reference to the master
conntrack from ctnetlink_create_expect().

However, the delete expectation command needs to grab the spinlock
before looking up for the expectation. Expand the existing spinlock
section to address this to cover the expectation lookup. Note that,
the nf_ct_expect_iterate_net() calls already grabs the spinlock while
iterating over the expectation table, which is correct.

The get expectation command needs to grab the spinlock to ensure master
conntrack does not go away. This also expands the existing spinlock
section to cover the expectation lookup too. I needed to move the
netlink skb allocation out of the spinlock to keep it GFP_KERNEL.

For the expectation events, the IPEXP_DESTROY event is already delivered
under the spinlock, just move the delivery of IPEXP_NEW under the
spinlock too because the master conntrack event cache is reached through
exp->master.

While at it, add lockdep notations to help identify what codepaths need
to grab the spinlock.

Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the verification I need. Let me compile the final
analysis.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**
Record: [netfilter: ctnetlink] [ensure] [safe access to master conntrack
— "ensure" strongly implies a missing safety mechanism, i.e., a bug fix]

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Signed-off-by: Florian Westphal <fw@strlen.de> — Author, core
  netfilter developer
- Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> — Netfilter
  subsystem maintainer
- No Fixes: tag (expected for manual review)
- No Cc: stable tag (expected for manual review)
- No Reported-by:, Tested-by:, Reviewed-by:, or Link: tags

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record: The commit describes a real lifetime bug: holding a reference on
the expectation is not sufficient because the master conntrack object
`exp->master` can be freed independently, leaving a dangling pointer.
The fix serializes access via `nf_conntrack_expect_lock`, which overlaps
with `clean_from_lists()` in the conntrack teardown path. Affected
paths: expectation get, delete, and IPEXP_NEW event delivery. The
failure mode is a use-after-free / stale pointer dereference through
`exp->master`.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: This IS a bug fix. Despite using "ensure" rather than "fix", the
body explicitly describes a use-after-free class bug where `exp->master`
becomes invalid.

===============================================================
PHASE 2: DIFF ANALYSIS — LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**
Record:
- `include/net/netfilter/nf_conntrack_core.h`: +5 lines (new
  `lockdep_nfct_expect_lock_held()` inline)
- `net/netfilter/nf_conntrack_ecache.c`: +2 lines (lockdep annotation in
  `nf_ct_expect_event_report`)
- `net/netfilter/nf_conntrack_expect.c`: +9/-1 lines (lockdep
  annotations; IPEXP_NEW moved inside lock)
- `net/netfilter/nf_conntrack_netlink.c`: +22/-12 lines (spinlock
  sections extended in get/delete)

Total: ~38 insertions, ~13 deletions across 4 files. Scope: small,
single-subsystem surgical locking fix.

Functions modified: `lockdep_nfct_expect_lock_held()` (new trivial
helper), `nf_ct_expect_event_report()`, `nf_ct_unlink_expect_report()`,
`nf_ct_remove_expect()`, `nf_ct_find_expectation()`,
`__nf_ct_expect_check()`, `nf_ct_expect_related_report()`,
`ctnetlink_get_expect()`, `ctnetlink_del_expect()`.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
- `ctnetlink_get_expect()`: Before — finds expectation via
  `nf_ct_expect_find_get()` under RCU, then fills reply skb
  dereferencing `exp->master` without expect lock. After — allocates skb
  first (GFP_KERNEL), takes `nf_conntrack_expect_lock`, does lookup +
  fill under lock, releases lock after put.
- `ctnetlink_del_expect()`: Before — finds expectation and checks ID
  before taking lock; only deletion protected. After — takes lock first,
  find + ID check + deletion all under lock.
- `nf_ct_expect_related_report()`: Before — unlocks before calling
  `nf_ct_expect_event_report(IPEXP_NEW, ...)`. After — delivers
  IPEXP_NEW under lock, then unlocks.
- Lockdep annotations added to `nf_ct_expect_event_report`,
  `nf_ct_unlink_expect_report`, `nf_ct_remove_expect`,
  `nf_ct_find_expectation`, and `__nf_ct_expect_check` to document and
  enforce locking requirements.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: Category: **Race condition → Use-after-free on `exp->master`**.

The race:
1. Thread A (ctnetlink GET/DELETE): calls `nf_ct_expect_find_get()`
   which bumps `exp->use` but does NOT pin the master conntrack
2. Thread B (conntrack destruction): `clean_from_lists()` →
   `nf_ct_remove_expectations()` → takes `nf_conntrack_expect_lock`,
   removes expectations
3. Thread B continues: master conntrack `nf_conn` object freed via RCU
4. Thread A: dereferences `exp->master` → **USE-AFTER-FREE**

Verified: `clean_from_lists()` at line 511 of `nf_conntrack_core.c`
calls `nf_ct_remove_expectations(ct)`, which takes
`nf_conntrack_expect_lock` at line 238 of `nf_conntrack_expect.c`. After
expectations are removed, the master ct is freed.

The specific `exp->master` dereferences in `ctnetlink_exp_dump_expect()`
(lines 3012-3067 of `nf_conntrack_netlink.c`) include:
- `master->tuplehash[IP_CT_DIR_ORIGINAL].tuple` (line 3029)
- `nf_ct_l3num(master)` and `nf_ct_protonum(master)` (lines 3043, 3045)
- `nfct_help(master)` (line 3059)

In `nf_ct_expect_event_report()`, `nf_ct_ecache_find(exp->master)`
dereferences the master conntrack.

**Step 2.4: ASSESS THE FIX QUALITY**
Record: The fix is obviously correct — it extends the existing
`nf_conntrack_expect_lock` to cover accesses that were previously
unprotected. The `GFP_KERNEL` skb allocation is moved before the lock to
avoid sleeping under spinlock. IPEXP_DESTROY was already delivered under
the lock; now IPEXP_NEW is too. Very low regression risk — slightly
longer lock hold on admin netlink paths.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**
Record: `git blame` confirms the core of `ctnetlink_get_expect()` was
introduced by `c1d10adb4a521d` (Pablo Neira Ayuso, 2006-01-05) —
original ctnetlink support. The unlocked expectation lookup pattern has
existed since kernel 2.6.x and is present in ALL active stable trees.

**Step 3.2: FOLLOW THE FIXES TAG**
Record: N/A — no Fixes: tag present.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: Recent git log for `nf_conntrack_netlink.c` shows multiple
related UAF/refcount fixes in the same code:
- `cd541f15b60e2` — "fix use-after-free in ctnetlink_dump_exp_ct()" —
  KASAN slab-use-after-free confirmed in expectation dumping
- `1492e3dcb2be3` — "remove refcounting in expectation dumpers"
- `de788b2e62274` — "fix refcount leak on table dump"

The `cd541f15b60e2` commit includes an actual KASAN stack trace proving
UAF bugs in this exact code area are real and exploitable.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Florian Westphal is a core netfilter developer (verified via
MAINTAINERS and git log). Pablo Neira Ayuso is THE netfilter subsystem
maintainer. Both SOBs on this commit.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: The diff is self-contained. The new
`lockdep_nfct_expect_lock_held()` is trivial (wraps
`lockdep_assert_held`). All referenced functions and data structures
exist in current stable trees. No external dependencies detected.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: SEARCH LORE.KERNEL.ORG**
Record: Direct lore.kernel.org access blocked by Anubis proof-of-work.
Alternate sources: spinics.net netdev archive and patchwork.ozlabs.org
confirmed v1→v2→v3 iterations. The v3 cover letter states: "patches 5 to
10 address long-standing RCU safety bugs in conntrack's handling of
expectations."

**Step 4.2: SEARCH FOR BUG REPORT**
Record: No standalone syzbot report or specific bug report for this
exact race, but the related commit `cd541f15b60e2` has a confirmed KASAN
slab-use-after-free trace proving this class of bugs is real and
triggerable.

**Step 4.3: CHECK FOR RELATED PATCHES**
Record: Part of a multi-patch series addressing expectation safety. This
specific patch is standalone — it only extends locking and adds lockdep
annotations, independent of companion patches.

**Step 4.4: CHECK STABLE MAILING LIST**
Record: Could not verify stable-specific discussion due to lore access
issues.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: KEY FUNCTIONS**
Record: `ctnetlink_get_expect`, `ctnetlink_del_expect`,
`nf_ct_expect_related_report`, `nf_ct_expect_event_report`,
`ctnetlink_exp_dump_expect`

**Step 5.2: TRACE CALLERS**
Record: Verified `ctnetlink_get_expect` and `ctnetlink_del_expect` are
wired into the `ctnl_exp_cb` netlink callback table (lines 3830-3848 of
`nf_conntrack_netlink.c`) for `IPCTNL_MSG_EXP_GET` and
`IPCTNL_MSG_EXP_DELETE`. These are directly reachable from userspace via
`AF_NETLINK`/`NETLINK_NETFILTER` (requires `CAP_NET_ADMIN`).

`nf_ct_expect_related()` (wrapper around
`nf_ct_expect_related_report()`) is called from 16+ files including SIP,
H323, FTP, IRC, TFTP, AMANDA, broadcast, nft_ct, PPTP, SANE, NAT
helpers, and IPVS. This is NOT a niche path.

**Step 5.3: TRACE CALLEES**
Record: `ctnetlink_exp_dump_expect()` (lines 3008-3077) dereferences
`exp->master` extensively: `master->tuplehash`, `nf_ct_l3num(master)`,
`nf_ct_protonum(master)`, `nfct_help(master)`.
`nf_ct_expect_event_report()` calls `nf_ct_ecache_find(exp->master)`.

**Step 5.4: FOLLOW CALL CHAIN**
Record: Userspace → nfnetlink_rcv → nfnetlink_rcv_msg →
ctnetlink_get/del_expect → nf_ct_expect_find_get → exp->master
dereference. Directly reachable from userspace with CAP_NET_ADMIN.

**Step 5.5: SIMILAR PATTERNS**
Record: `expect_iter_name()` in v6.6 also dereferences `exp->master` via
`nfct_help(exp->master)` — same class of vulnerability in the same file.

===============================================================
PHASE 6: STABLE TREE ANALYSIS
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
Record: **YES** — verified directly. In v6.6:
- `ctnetlink_get_expect()` does `nf_ct_expect_find_get()` at line 3333
  WITHOUT `nf_conntrack_expect_lock`, then calls
  `ctnetlink_exp_fill_info()` which dereferences `exp->master`
- `ctnetlink_del_expect()` does `nf_ct_expect_find_get()` at line 3408
  before taking `nf_conntrack_expect_lock` at line 3421
- `nf_ct_expect_related_report()` unlocks at line 501, THEN calls
  `nf_ct_expect_event_report(IPEXP_NEW, ...)` at line 502

The buggy code originated in 2006 (`c1d10adb4a521d`) and is present in
ALL active stable trees (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y).

**Step 6.2: BACKPORT COMPLICATIONS**
Record: Minor API differences in older trees: `timer_delete` vs
`del_timer` (treewide rename in `8fa7292fee5c5`), and the `struct
nfnl_info` ctnetlink interface. Core logic change (extending spinlock
sections) applies conceptually. Expected: clean or near-clean apply on
6.6+; minor manual adaptation needed for 5.x trees.

**Step 6.3: RELATED FIXES IN STABLE**
Record: `cd541f15b60e2` (KASAN UAF fix in ctnetlink_dump_exp_ct) is
already in stable. No alternative fix for the specific
get/delete/IPEXP_NEW races addressed by this patch.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: SUBSYSTEM AND CRITICALITY**
Record: [netfilter / conntrack / ctnetlink] [IMPORTANT — widely deployed
in firewalls, NAT gateways, containers, Kubernetes, orchestration
tooling, conntrack-tools monitoring]

**Step 7.2: SUBSYSTEM ACTIVITY**
Record: Active subsystem with frequent fixes. The longstanding nature of
the bug (2006) means it affects more stable trees.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Systems using conntrack expectations (FTP/SIP/H323/TFTP/IRC/etc.
helpers) AND userspace tools querying/managing expectations via
ctnetlink (conntrack-tools, orchestration). Also affected: any path
creating expectations that triggers IPEXP_NEW events.

**Step 8.2: DETERMINE TRIGGER CONDITIONS**
Record: Concurrent expectation access (GET/DELETE via netlink, or
IPEXP_NEW event delivery) with master conntrack destruction (normal
connection timeout/teardown). Timing-dependent race but realistic under
load — high conntrack churn with active monitoring is a real-world
scenario.

**Step 8.3: FAILURE MODE SEVERITY**
Record: UAF on `exp->master` → kernel crash/oops (accessing freed slab
memory), memory corruption, or potential security vulnerability.
Severity: **HIGH**. This is corroborated by the KASAN slab-use-after-
free trace in the related commit `cd541f15b60e2`.

**Step 8.4: RISK-BENEFIT RATIO**
Record:
- **Benefit: HIGH** — closes verified unsafe dereference windows in
  userspace-facing netlink operations and expectation event delivery
- **Risk: VERY LOW** — extends existing lock scope slightly, no new
  APIs, no logic changes, GFP_KERNEL allocation correctly moved out of
  lock
- **Ratio: Strongly favorable**

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

Evidence FOR backporting:
- Fixes a real use-after-free race condition on `exp->master` in
  ctnetlink
- Bug has existed since 2006 (commit `c1d10adb4a521d`), present in ALL
  active stable trees
- Verified directly: v6.6 has the same vulnerable pattern (unlocked
  expectation lookup + exp->master dereference)
- Written by netfilter subsystem maintainer (Pablo Neira Ayuso) and core
  developer (Florian Westphal)
- Small, surgical fix (~38 insertions, ~13 deletions) across 4 files in
  one subsystem
- Reachable from userspace via AF_NETLINK/NETLINK_NETFILTER
  (CAP_NET_ADMIN)
- Related KASAN UAF confirmed in same code area (`cd541f15b60e2`)
- IPEXP_NEW event path affects 16+ helper/NAT modules — not a niche path
- Part of a series explicitly described as fixing "long-standing RCU
  safety bugs" in expectations
- Low regression risk — only extends existing lock scope

Evidence AGAINST backporting:
- No specific crash report or syzbot report for THIS exact race window
- Part of a multi-patch series (but this patch is standalone)
- May need minor manual adaptation for older stable trees (API renames)

**Step 9.2: STABLE RULES CHECKLIST**
1. Obviously correct and tested? **YES** — extends lock to cover
   unprotected accesses; pattern matches existing serialization
2. Fixes a real bug? **YES** — UAF on `exp->master`, verified via code
   analysis and corroborated by related KASAN reports
3. Important issue? **YES** — crash, memory corruption, potential
   security (UAF from userspace-triggerable netlink path)
4. Small and contained? **YES** — ~50 lines net across 4 files in one
   subsystem
5. No new features or APIs? **YES** — only lockdep annotation helper
   added (debug instrumentation)
6. Can apply to stable? **YES** — may need minor adaptation for API
   renames in older trees

**Step 9.3: EXCEPTION CATEGORIES**
Record: N/A — this is a standard bug fix, not an exception category.

**Step 9.4: DECISION**
This commit fixes a real, longstanding use-after-free race condition in
netfilter conntrack expectation handling that can lead to kernel crashes
or memory corruption. The fix is small, surgical, obviously correct,
authored by the subsystem maintainer and core developer, and applies to
all active stable trees. The risk-benefit ratio is strongly favorable.

## Verification

- [Phase 1] Parsed commit message: only SOBs from Florian Westphal and
  Pablo Neira Ayuso; no Fixes/Reported-by/Cc:stable tags
- [Phase 2] Read `ctnetlink_exp_dump_expect()` at lines 3008-3077 of
  `nf_conntrack_netlink.c`: confirmed multiple `exp->master`
  dereferences (`master->tuplehash`, `nf_ct_l3num(master)`,
  `nfct_help(master)`)
- [Phase 2] Read `clean_from_lists()` at line 511 of
  `nf_conntrack_core.c`: confirmed it calls
  `nf_ct_remove_expectations(ct)` before master ct is freed
- [Phase 2] Read `nf_ct_remove_expectations()` at line 228 of
  `nf_conntrack_expect.c`: confirmed it takes `nf_conntrack_expect_lock`
  at line 238 — this is the serialization point
- [Phase 2] Read `nf_ct_expect_related_report()` at line 500-507:
  confirmed `spin_unlock_bh` at line 501 THEN
  `nf_ct_expect_event_report(IPEXP_NEW)` at line 502 — the unlocked
  window
- [Phase 3] `git blame` on `ctnetlink_get_expect`: lines 3342, 3354-3362
  trace to `c1d10adb4a521d` (Pablo Neira Ayuso, 2006-01-05)
- [Phase 3] `git log --oneline -20 --
  net/netfilter/nf_conntrack_netlink.c`: found related UAF fixes
  `cd541f15b60e2`, `1492e3dcb2be3`, `de788b2e62274`
- [Phase 3] `git show cd541f15b60e2`: confirmed KASAN slab-use-after-
  free stack trace in same ctnetlink expectation code
- [Phase 3] `git log --author` for both authors: verified as core
  netfilter contributors
- [Phase 4] Lore.kernel.org blocked by Anubis; used spinics.net and
  patchwork.ozlabs.org mirrors to verify v1→v2→v3 iterations and cover
  letter content
- [Phase 5] Read `ctnl_exp_cb` callback table at lines 3830-3848:
  confirmed `ctnetlink_get_expect` and `ctnetlink_del_expect` are
  userspace-reachable via NETLINK_NETFILTER
- [Phase 5] `rg nf_ct_expect_related` across net/netfilter/: 16 files
  use this function (SIP, FTP, H323, TFTP, IRC, AMANDA, broadcast,
  nft_ct, PPTP, SANE, NAT helpers, IPVS)
- [Phase 6] `git show v6.6:net/netfilter/nf_conntrack_netlink.c`:
  confirmed unlocked `nf_ct_expect_find_get()` at line 3333 and
  `ctnetlink_exp_fill_info()` dereferences `exp->master` without expect
  lock
- [Phase 6] `git show v6.6:net/netfilter/nf_conntrack_expect.c`:
  confirmed `spin_unlock_bh` at line 501, then
  `nf_ct_expect_event_report(IPEXP_NEW)` at line 502 — same vulnerable
  pattern as mainline
- [Phase 8] Failure mode: UAF on `exp->master` → kernel
  crash/corruption; severity HIGH (corroborated by KASAN trace in
  related commit)
- UNVERIFIED: Exact privilege requirements for ctnetlink expectation
  operations (assumed CAP_NET_ADMIN based on netfilter conventions)
- UNVERIFIED: Whether patch applies cleanly to stable trees older than
  6.6 (API renames expected)
- UNVERIFIED: Full lore.kernel.org review thread (blocked by Anubis
  proof-of-work)
- UNVERIFIED: Stable trees older than v5.15 individually checked

**YES**

 include/net/netfilter/nf_conntrack_core.h |  5 ++++
 net/netfilter/nf_conntrack_ecache.c       |  2 ++
 net/netfilter/nf_conntrack_expect.c       | 10 +++++++-
 net/netfilter/nf_conntrack_netlink.c      | 28 +++++++++++++++--------
 4 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/include/net/netfilter/nf_conntrack_core.h b/include/net/netfilter/nf_conntrack_core.h
index 3384859a89210..8883575adcc1e 100644
--- a/include/net/netfilter/nf_conntrack_core.h
+++ b/include/net/netfilter/nf_conntrack_core.h
@@ -83,6 +83,11 @@ void nf_conntrack_lock(spinlock_t *lock);
 
 extern spinlock_t nf_conntrack_expect_lock;
 
+static inline void lockdep_nfct_expect_lock_held(void)
+{
+	lockdep_assert_held(&nf_conntrack_expect_lock);
+}
+
 /* ctnetlink code shared by both ctnetlink and nf_conntrack_bpf */
 
 static inline void __nf_ct_set_timeout(struct nf_conn *ct, u64 timeout)
diff --git a/net/netfilter/nf_conntrack_ecache.c b/net/netfilter/nf_conntrack_ecache.c
index 81baf20826046..9df159448b897 100644
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -247,6 +247,8 @@ void nf_ct_expect_event_report(enum ip_conntrack_expect_events event,
 	struct nf_ct_event_notifier *notify;
 	struct nf_conntrack_ecache *e;
 
+	lockdep_nfct_expect_lock_held();
+
 	rcu_read_lock();
 	notify = rcu_dereference(net->ct.nf_conntrack_event_cb);
 	if (!notify)
diff --git a/net/netfilter/nf_conntrack_expect.c b/net/netfilter/nf_conntrack_expect.c
index cfc2daa3fc7f3..f9e65f03dc5ea 100644
--- a/net/netfilter/nf_conntrack_expect.c
+++ b/net/netfilter/nf_conntrack_expect.c
@@ -51,6 +51,7 @@ void nf_ct_unlink_expect_report(struct nf_conntrack_expect *exp,
 	struct net *net = nf_ct_exp_net(exp);
 	struct nf_conntrack_net *cnet;
 
+	lockdep_nfct_expect_lock_held();
 	WARN_ON(!master_help);
 	WARN_ON(timer_pending(&exp->timeout));
 
@@ -118,6 +119,8 @@ nf_ct_exp_equal(const struct nf_conntrack_tuple *tuple,
 
 bool nf_ct_remove_expect(struct nf_conntrack_expect *exp)
 {
+	lockdep_nfct_expect_lock_held();
+
 	if (timer_delete(&exp->timeout)) {
 		nf_ct_unlink_expect(exp);
 		nf_ct_expect_put(exp);
@@ -177,6 +180,8 @@ nf_ct_find_expectation(struct net *net,
 	struct nf_conntrack_expect *i, *exp = NULL;
 	unsigned int h;
 
+	lockdep_nfct_expect_lock_held();
+
 	if (!cnet->expect_count)
 		return NULL;
 
@@ -442,6 +447,8 @@ static inline int __nf_ct_expect_check(struct nf_conntrack_expect *expect,
 	unsigned int h;
 	int ret = 0;
 
+	lockdep_nfct_expect_lock_held();
+
 	if (!master_help) {
 		ret = -ESHUTDOWN;
 		goto out;
@@ -498,8 +505,9 @@ int nf_ct_expect_related_report(struct nf_conntrack_expect *expect,
 
 	nf_ct_expect_insert(expect);
 
-	spin_unlock_bh(&nf_conntrack_expect_lock);
 	nf_ct_expect_event_report(IPEXP_NEW, expect, portid, report);
+	spin_unlock_bh(&nf_conntrack_expect_lock);
+
 	return 0;
 out:
 	spin_unlock_bh(&nf_conntrack_expect_lock);
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index d9f33a6c807c8..f5cb09eb31a34 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -3357,31 +3357,37 @@ static int ctnetlink_get_expect(struct sk_buff *skb,
 	if (err < 0)
 		return err;
 
+	skb2 = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+	if (!skb2)
+		return -ENOMEM;
+
+	spin_lock_bh(&nf_conntrack_expect_lock);
 	exp = nf_ct_expect_find_get(info->net, &zone, &tuple);
-	if (!exp)
+	if (!exp) {
+		spin_unlock_bh(&nf_conntrack_expect_lock);
+		kfree_skb(skb2);
 		return -ENOENT;
+	}
 
 	if (cda[CTA_EXPECT_ID]) {
 		__be32 id = nla_get_be32(cda[CTA_EXPECT_ID]);
 
 		if (id != nf_expect_get_id(exp)) {
 			nf_ct_expect_put(exp);
+			spin_unlock_bh(&nf_conntrack_expect_lock);
+			kfree_skb(skb2);
 			return -ENOENT;
 		}
 	}
 
-	skb2 = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
-	if (!skb2) {
-		nf_ct_expect_put(exp);
-		return -ENOMEM;
-	}
-
 	rcu_read_lock();
 	err = ctnetlink_exp_fill_info(skb2, NETLINK_CB(skb).portid,
 				      info->nlh->nlmsg_seq, IPCTNL_MSG_EXP_NEW,
 				      exp);
 	rcu_read_unlock();
 	nf_ct_expect_put(exp);
+	spin_unlock_bh(&nf_conntrack_expect_lock);
+
 	if (err <= 0) {
 		kfree_skb(skb2);
 		return -ENOMEM;
@@ -3431,22 +3437,26 @@ static int ctnetlink_del_expect(struct sk_buff *skb,
 		if (err < 0)
 			return err;
 
+		spin_lock_bh(&nf_conntrack_expect_lock);
+
 		/* bump usage count to 2 */
 		exp = nf_ct_expect_find_get(info->net, &zone, &tuple);
-		if (!exp)
+		if (!exp) {
+			spin_unlock_bh(&nf_conntrack_expect_lock);
 			return -ENOENT;
+		}
 
 		if (cda[CTA_EXPECT_ID]) {
 			__be32 id = nla_get_be32(cda[CTA_EXPECT_ID]);
 
 			if (id != nf_expect_get_id(exp)) {
 				nf_ct_expect_put(exp);
+				spin_unlock_bh(&nf_conntrack_expect_lock);
 				return -ENOENT;
 			}
 		}
 
 		/* after list removal, usage count == 1 */
-		spin_lock_bh(&nf_conntrack_expect_lock);
 		if (timer_delete(&exp->timeout)) {
 			nf_ct_unlink_expect_report(exp, NETLINK_CB(skb).portid,
 						   nlmsg_report(info->nlh));
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.6] RDMA/irdma: Fix double free related to rereg_user_mr

[Sasha Levin]

From: Jacob Moroni <jmoroni@google.com>

[ Upstream commit 29a3edd7004bb635d299fb9bc6f0ea4ef13ed5a2 ]

If IB_MR_REREG_TRANS is set during rereg_user_mr, the
umem will be released and a new one will be allocated
in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans
fails after the new umem is allocated, it releases the umem,
but does not set iwmr->region to NULL. The problem is that
this failure is propagated to the user, who will then call
ibv_dereg_mr (as they should). Then, the dereg_mr path will
see a non-NULL umem and attempt to call ib_umem_release again.

Fix this by setting iwmr->region to NULL after ib_umem_release.

Fixed: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region")
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Link: https://patch.msgid.link/20260227152743.1183388-1-jmoroni@google.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the facts. Here is my complete analysis:

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [RDMA/irdma] [Fix] [double free related to rereg_user_mr — stale
`iwmr->region` pointer after error in `irdma_rereg_mr_trans`]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Fixed:** `5ac388db27c4` ("RDMA/irdma: Add support to re-register a
  memory region") — Note: uses `Fixed:` instead of the standard `Fixes:`
  tag, but semantically identical. This identifies the commit that
  introduced the bug.
- **Signed-off-by:** Jacob Moroni <jmoroni@google.com> (author)
- **Link:**
  https://patch.msgid.link/20260227152743.1183388-1-jmoroni@google.com
- **Signed-off-by:** Leon Romanovsky <leon@kernel.org> (RDMA subsystem
  maintainer)
- No Reported-by, Tested-by, Reviewed-by, Acked-by, or Cc: stable tags
  present.

Record: Author from Google with prior RDMA double-free fixes (e.g.,
`40126bcbefa79 RDMA/umem: Fix double dma_buf_unpin in failure path`).
Accepted through the RDMA maintainer tree (Leon Romanovsky).

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit message precisely describes the bug mechanism:
1. When `IB_MR_REREG_TRANS` is set, `irdma_rereg_user_mr()` releases the
   old umem and NULLs `iwmr->region`.
2. `irdma_rereg_mr_trans()` allocates a new umem and stores it in
   `iwmr->region` (line 3700).
3. If a later step fails (page_size check or
   `irdma_reg_user_mr_type_mem()`), the `err:` path calls
   `ib_umem_release(region)` but does NOT set `iwmr->region = NULL`.
4. Error propagates to userspace. User correctly calls `ibv_dereg_mr`.
5. `irdma_dereg_mr()` sees non-NULL `iwmr->region` at line 3932 and
   calls `ib_umem_release()` again — double free.

Record: Bug = double free of ib_umem. Symptom = kernel crash, memory
corruption, or potential security vulnerability. Root cause = stale
pointer in `iwmr->region` after error-path free.

### Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not hidden — explicitly labeled "Fix double free." This is a
direct, clear memory-safety bug fix.

---

## PHASE 2: DIFF ANALYSIS — LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
Record: **1 file**: `drivers/infiniband/hw/irdma/verbs.c`, **+1 line**
added. Function modified: `irdma_rereg_mr_trans()`. Scope: single-file,
single-line surgical fix.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Before the fix, the `err:` label at line 3721 runs:

```3721:3723:drivers/infiniband/hw/irdma/verbs.c
err:
        ib_umem_release(region);
        return err;
```

After the fix, it becomes:
```c
err:
        ib_umem_release(region);
        iwmr->region = NULL;
        return err;
```

Record: Before = freed memory, left dangling pointer in `iwmr->region`.
After = freed memory, set `iwmr->region = NULL` to prevent double-free
in `irdma_dereg_mr()`.

### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Double-free / memory safety**.

The confirmed double-free path:
1. Line 3700: `iwmr->region = region;` — stores new umem pointer
2. Lines 3706-3717: possible failure paths (`goto err`)
3. Line 3722: `ib_umem_release(region);` — frees the umem
4. Line 3723: returns error (but `iwmr->region` still points to freed
   memory)
5. Later, in `irdma_dereg_mr()`:

```3932:3933:drivers/infiniband/hw/irdma/verbs.c
        if (iwmr->region)
                ib_umem_release(iwmr->region);
```

This calls `ib_umem_release()` on already-freed memory. Verified that
`ib_umem_release()` dereferences the `umem` object, unpins pages, and
calls `kfree(umem)` (confirmed in `drivers/infiniband/core/umem.c` lines
284-298).

Record: Double-free of `ib_umem` object. The second `ib_umem_release()`
dereferences freed memory and kfree's it again.

### Step 2.4: ASSESS THE FIX QUALITY
The fix is obviously correct: it sets `iwmr->region = NULL` after
freeing the object, which is the standard kernel pattern for preventing
double-frees. This **exactly matches** the existing pattern in the same
file — `irdma_rereg_user_mr()` already does this at lines 3775-3777:

```3775:3778:drivers/infiniband/hw/irdma/verbs.c
                if (iwmr->region) {
                        ib_umem_release(iwmr->region);
                        iwmr->region = NULL;
                }
```

Record: Fix is obviously correct, minimal, follows existing code
conventions, zero regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
Git blame confirms every line in `irdma_rereg_mr_trans()` (lines
3696-3723) was introduced by commit `5ac388db27c4` (Sindhu Devale,
2023-10-04). The bug has existed since the function was first written.

Record: Buggy code introduced in `5ac388db27c4`, first appeared in
v6.7-rc1.

### Step 3.2: FOLLOW THE FIXES: TAG
`git show 5ac388db27c4` confirms it added the entire MR re-registration
support to irdma, including `irdma_rereg_mr_trans()`,
`irdma_rereg_user_mr()`, and `.rereg_user_mr` in the device ops table.

`git describe --contains 5ac388db27c4` → `v6.7-rc1~96^2~21` — first
released in v6.7.

`git merge-base --is-ancestor 5ac388db27c4 v6.6` → exit 1 (NOT in v6.6).
`git merge-base --is-ancestor 5ac388db27c4 v6.7` → exit 0 (IS in v6.7).

`git grep irdma_rereg_mr_trans v6.6` → no match.
`git grep irdma_rereg_mr_trans v6.12` → match (3 references).

Record: Original buggy commit exists in v6.7+ stable trees. NOT in
v6.6.y or older. Bug present since inception of the function.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Recent file history shows active irdma maintenance but no related fix
for this specific double-free. No prerequisite commits needed.

Record: Standalone fix, no dependencies.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Jacob Moroni has multiple RDMA commits including `40126bcbefa79
RDMA/umem: Fix double dma_buf_unpin in failure path` — another double-
free fix in RDMA umem handling. This demonstrates relevant domain
expertise.

Record: Author is an active RDMA contributor with prior double-free
fixes. Patch accepted by RDMA subsystem maintainer Leon Romanovsky.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
The fix is a single-line NULL assignment in an existing error path. No
dependencies.

Record: Fully standalone, clean apply expected.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Steps 4.1-4.4
Lore.kernel.org access was blocked by Anubis proof-of-work page. The
patch.msgid.link URL was also inaccessible. Web searches did not locate
a mirror of the exact patch discussion.

However, the patch was accepted through the standard RDMA maintainer
tree (Signed-off-by: Leon Romanovsky), indicating it passed normal
review.

Record: UNVERIFIED: Could not access mailing list discussion due to
anti-bot measures. No additional context about reviewer feedback or
stable nominations.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS
- `irdma_rereg_mr_trans()` — modified (error path)
- `irdma_rereg_user_mr()` — caller, wired as `.rereg_user_mr` in device
  ops
- `irdma_dereg_mr()` — site of the second (double) free, wired as
  `.dereg_mr`

### Step 5.2: TRACE CALLERS
- `irdma_rereg_user_mr()` is registered as `.rereg_user_mr` in the irdma
  device ops
- RDMA core's `ib_uverbs_rereg_mr()` (in
  `drivers/infiniband/core/uverbs_cmd.c`) calls
  `ib_dev->ops.rereg_user_mr()`
- This is reachable from userspace via RDMA uverbs

The double-free path:
- Userspace `ibv_dereg_mr` → RDMA core MR destroy → `ib_dereg_mr_user()`
  → `irdma_dereg_mr()` → `ib_umem_release(iwmr->region)` on dangling
  pointer

Record: Both entry points (rereg and dereg) are userspace-reachable
through RDMA uverbs.

### Step 5.3: TRACE CALLEES
`ib_umem_release()` (confirmed at `drivers/infiniband/core/umem.c:284`)
dereferences the `umem` object, unpins pages via `__ib_umem_release()`,
decrements `pinned_vm`, calls `mmdrop()`, and finally `kfree(umem)`. A
second call on the same freed pointer is a genuine double-free with
memory corruption.

### Step 5.4: CALL CHAIN REACHABILITY
Userspace → `ibv_rereg_mr` → `ib_uverbs_rereg_mr()` →
`irdma_rereg_user_mr()` → `irdma_rereg_mr_trans()` (fails) → returns
error to user → user calls `ibv_dereg_mr` → `irdma_dereg_mr()` → double
free.

Record: Fully userspace-reachable path on systems with irdma hardware.

### Step 5.5: SIMILAR PATTERNS
The caller `irdma_rereg_user_mr()` already correctly does
`ib_umem_release(iwmr->region); iwmr->region = NULL;` at lines
3775-3777, establishing the pattern. The omission in
`irdma_rereg_mr_trans()` is an inconsistency with the file's own
conventions.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
- **v6.6.y**: NOT present (confirmed via `git grep` — no match for
  `irdma_rereg_mr_trans`)
- **v6.12.y**: Present (confirmed via `git grep` — 3 references found)
- **v6.7+**: All trees contain the buggy code

Record: Affects stable trees v6.7 and newer (including 6.12.y). NOT
applicable to v6.6.y or older.

### Step 6.2: BACKPORT COMPLICATIONS
The one-line fix in an unchanged error path should apply cleanly to all
trees containing the function.

Record: Expected clean apply, no conflicts.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
`git log --grep="double free" --grep="rereg_user_mr"` — no results. The
fix is not yet in any tree.

Record: No related fix already applied.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- Subsystem: RDMA / irdma driver (`drivers/infiniband/hw/irdma/`)
- Criticality: IMPORTANT for RDMA deployments — Intel iWARP hardware
  used in data centers, HPC, and cloud infrastructure. While not core-mm
  universal, a kernel memory-safety bug on a userspace-reachable path
  has security implications.

### Step 7.2: SUBSYSTEM ACTIVITY
Actively maintained — 15+ recent commits show ongoing bug fixes and
development.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users of Intel RDMA (irdma) hardware who use MR re-registration with the
`IB_MR_REREG_TRANS` flag.

Record: Driver-specific (irdma users), but these are often production
data center systems.

### Step 8.2: TRIGGER CONDITIONS
1. Userspace calls `ibv_rereg_mr` with `IB_MR_REREG_TRANS`
2. `irdma_rereg_mr_trans()` fails after allocating the new umem (either
   `ib_umem_find_best_pgsz()` returns 0 or
   `irdma_reg_user_mr_type_mem()` fails)
3. User then correctly calls `ibv_dereg_mr` to clean up

This is a deterministic error-path trigger, not a timing race. Any
application hitting a registration failure and cleaning up properly will
trigger it.

Record: Deterministic trigger on error path. Userspace-reachable.

### Step 8.3: FAILURE MODE SEVERITY
Double-free of a `ib_umem` structure. `ib_umem_release()` dereferences
multiple fields and calls `kfree()`. A second call on freed memory
causes:
- Heap corruption (SLAB allocator corruption)
- Kernel crash / oops
- Potential security vulnerability (exploitable heap corruption)

Record: Severity: **CRITICAL** (double-free of kernel heap object on
userspace-triggerable path)

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit:** HIGH — prevents a double-free / memory corruption on a
  userspace-reachable error path
- **Risk:** VERY LOW — single line `iwmr->region = NULL;` after free,
  follows existing code pattern, obviously correct
- **Ratio:** Extremely favorable for backporting

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Verified double-free of `ib_umem` object on a userspace-reachable
  error path
- `ib_umem_release()` confirmed to dereference and `kfree()` the object
- Single-line, obviously correct fix (NULL-after-free)
- Matches existing code pattern in the same file (lines 3775-3777)
- Bug present since function was introduced in v6.7-rc1 (`5ac388db27c4`)
- Zero regression risk
- Author has prior RDMA double-free fix expertise
- Accepted by RDMA subsystem maintainer

**AGAINST backporting:**
- None.

**UNRESOLVED:**
- Could not access lore.kernel.org mailing list discussion (Anubis
  block)
- No independent crash report verified (no Reported-by tag)

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** — single-line NULL assignment
   after free, matches existing pattern
2. Fixes a real bug? **YES** — verified double-free via code path
   analysis
3. Important issue? **YES** — double-free = crash/corruption/potential
   security vulnerability (CRITICAL)
4. Small and contained? **YES** — 1 line, 1 file, 1 function error path
5. No new features or APIs? **YES** — pure bug fix
6. Can apply to stable trees? **YES** — clean apply expected on v6.7+
   trees

### Step 9.3: EXCEPTION CATEGORIES
N/A — this is a standard bug fix meeting all criteria directly.

### Step 9.4: DECISION
This is a textbook stable backport candidate: a one-line fix for a
verified double-free on a userspace-reachable path, with zero regression
risk, applicable to stable trees v6.7 and newer (not v6.6.y or older,
where the code does not exist).

---

## Verification

- [Phase 1] Parsed all tags from commit message: `Fixed: 5ac388db27c4`,
  `Link:`, two `Signed-off-by:` (author + maintainer). No Reported-
  by/Tested-by/Cc:stable.
- [Phase 2] Read `verbs.c` lines 3690-3724: confirmed `iwmr->region =
  region` at line 3700, `err:` path at lines 3721-3723 releases region
  without NULLing `iwmr->region`.
- [Phase 2] Read `verbs.c` lines 3905-3938: confirmed `irdma_dereg_mr()`
  checks `if (iwmr->region)` at line 3932 and calls
  `ib_umem_release(iwmr->region)` — this is the second free.
- [Phase 2] Read `drivers/infiniband/core/umem.c` lines 284-298:
  confirmed `ib_umem_release()` dereferences umem fields and calls
  `kfree(umem)`.
- [Phase 2] Verified existing NULL-after-free pattern at lines 3775-3777
  in `irdma_rereg_user_mr()`.
- [Phase 3] `git blame -L 3696,3723`: all lines from `5ac388db27c4`
  (Sindhu Devale, 2023-10-04).
- [Phase 3] `git show 5ac388db27c4`: confirmed it adds MR re-
  registration support including the buggy function.
- [Phase 3] `git describe --contains 5ac388db27c4` → `v6.7-rc1~96^2~21`.
- [Phase 3] `git merge-base --is-ancestor 5ac388db27c4 v6.6` → exit 1
  (NOT in v6.6).
- [Phase 3] `git merge-base --is-ancestor 5ac388db27c4 v6.7` → exit 0
  (IS in v6.7).
- [Phase 3] `git log --author="Jacob Moroni"`: found 10 RDMA commits
  including `40126bcbefa79 RDMA/umem: Fix double dma_buf_unpin in
  failure path`.
- [Phase 4] UNVERIFIED: Lore/patch discussion blocked by Anubis anti-bot
  page.
- [Phase 5] Grep for `if (iwmr->region)` in verbs.c: found at lines
  3775, 3912, and 3932 — all three sites depend on `iwmr->region`
  accurately reflecting ownership.
- [Phase 6] `git grep irdma_rereg_mr_trans v6.6` → no match (code absent
  from v6.6).
- [Phase 6] `git grep irdma_rereg_mr_trans v6.12` → 3 matches (code
  present in v6.12).
- [Phase 6] `git log --grep="double free" --grep="rereg_user_mr"` → no
  results (fix not yet applied anywhere).
- [Phase 8] Failure mode: double-free of `ib_umem` → heap corruption,
  crash, potential security exploit. Severity CRITICAL.
- UNVERIFIED: Mailing list reviewer feedback and stable nominations
  (lore blocked).
- UNVERIFIED: Whether an independent crash report exists beyond the
  author's finding.

**YES**

 drivers/infiniband/hw/irdma/verbs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/irdma/verbs.c b/drivers/infiniband/hw/irdma/verbs.c
index 68fb81b7bd221..18844d24973be 100644
--- a/drivers/infiniband/hw/irdma/verbs.c
+++ b/drivers/infiniband/hw/irdma/verbs.c
@@ -3720,6 +3720,7 @@ static int irdma_rereg_mr_trans(struct irdma_mr *iwmr, u64 start, u64 len,
 
 err:
 	ib_umem_release(region);
+	iwmr->region = NULL;
 	return err;
 }
 
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] can: mcp251x: add error handling for power enable in open and resume

[Sasha Levin]

From: Wenyuan Li <2063309626@qq.com>

[ Upstream commit 7a57354756c7df223abe2c33774235ad70cb4231 ]

Add missing error handling for mcp251x_power_enable() calls in both
mcp251x_open() and mcp251x_can_resume() functions.

In mcp251x_open(), if power enable fails, jump to error path to close
candev without attempting to disable power again.

In mcp251x_can_resume(), properly check return values of power enable calls
for both power and transceiver regulators. If any fails, return the error
code to the PM framework and log the failure.

This ensures the driver properly handles power control failures and
maintains correct device state.

Signed-off-by: Wenyuan Li <2063309626@qq.com>
Link: https://patch.msgid.link/tencent_F3EFC5D7738AC548857B91657715E2D3AA06@qq.com
[mkl: fix patch description]
[mkl: mcp251x_can_resume(): replace goto by return]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Parse the Subject Line
Record: [Subsystem: can: mcp251x] [Action verb: add] [Summary: add error
handling for `mcp251x_power_enable()` return values in `mcp251x_open()`
and `mcp251x_can_resume()`]

### Step 1.2: Parse All Commit Message Tags
Record:
- **Signed-off-by:** Wenyuan Li <2063309626@qq.com> (author)
- **Link:** `https://patch.msgid.link/tencent_F3EFC5D7738AC548857B916577
  15E2D3AA06@qq.com`
- `[mkl: fix patch description]` — Marc Kleine-Budde (CAN subsystem
  maintainer) edited the description
- `[mkl: mcp251x_can_resume(): replace goto by return]` — maintainer
  restructured the resume error path
- **Signed-off-by:** Marc Kleine-Budde <mkl@pengutronix.de> (CAN
  subsystem maintainer)
- No Fixes: tag (expected for manual review candidates)
- No Reported-by: (code inspection find)
- No Tested-by:, Reviewed-by:, Acked-by:, Cc: stable

Notable pattern: CAN subsystem maintainer actively modified the patch,
indicating hands-on review and approval.

### Step 1.3: Analyze the Commit Body Text
Record: Bug description — `mcp251x_power_enable()` return values are
ignored in both `mcp251x_open()` and `mcp251x_can_resume()`. In
`open()`, failure to enable the transceiver regulator allows the driver
to proceed with IRQ/SPI setup on unpowered hardware. The error path at
`out_close` then calls `mcp251x_power_enable(transceiver, 0)`, which
attempts to disable a regulator that was never enabled (unbalanced
disable). In `resume()`, regulator failures are silently ignored and
success is returned to the PM framework, allowing restart work to
proceed on failed hardware. No stack trace or specific user report
referenced.

### Step 1.4: Detect Hidden Bug Fixes
Record: This is an explicit error-handling bug fix, not hidden. "Add
error handling" directly addresses missing return-value checks and
incorrect cleanup. The phrase "ensures the driver properly handles power
control failures and maintains correct device state" confirms it is
fixing incorrect behavior.

---

## PHASE 2: DIFF ANALYSIS — LINE BY LINE

### Step 2.1: Inventory the Changes
Record:
- **Files:** `drivers/net/can/spi/mcp251x.c` (single file)
- **Net change:** approximately +23/-5 lines
- **Functions modified:** `mcp251x_open()`, `mcp251x_can_resume()`
- **Scope classification:** single-file, two-function, surgical fix

### Step 2.2: Understand the Code Flow Change

**Hunk 1 — `mcp251x_open()`:**
- **Before:** `mcp251x_power_enable(priv->transceiver, 1)` — return
  value discarded. On failure, driver proceeds with IRQ request, SPI
  setup, etc. All error paths fall through `out_close` which calls
  `mcp251x_power_enable(priv->transceiver, 0)`.
- **After:** Return value checked; on failure, jumps to new
  `out_close_candev` label that skips the transceiver disable (correct —
  don't disable what was never enabled) and goes directly to
  `close_candev(net)` + mutex_unlock.

**Hunk 2 — `mcp251x_can_resume()`:**
- **Before:** Both `mcp251x_power_enable(priv->power, 1)` and
  `mcp251x_power_enable(priv->transceiver, 1)` return values discarded.
  PM framework always told success. `queue_work`, `force_quit = 0`,
  `enable_irq` all proceed unconditionally.
- **After:** Each call checked. On power failure, return error
  immediately. On transceiver failure, roll back power (disable it if it
  was just enabled), then return error. PM framework gets actual error
  code.

### Step 2.3: Identify the Bug Mechanism

Record: **Bug category:** Error-path / logic correctness / regulator
state imbalance.

**Concrete bugs verified:**

1. **Regulator framework WARN() trigger**: I verified in
   `drivers/regulator/core.c` at line 3179:

```3179:3181:drivers/regulator/core.c
        if (WARN(regulator->enable_count == 0,
                 "unbalanced disables for %s\n", rdev_get_name(rdev)))
                return -EIO;
```

If `regulator_enable()` fails in `mcp251x_open()`, the `enable_count`
stays at 0. Then the error path at `out_close` calls
`mcp251x_power_enable(priv->transceiver, 0)` → `regulator_disable()` →
hits `enable_count == 0` → **triggers WARN()**.

2. **Silent resume failure**: `mcp251x_can_resume()` returns 0 (success)
   to PM framework even when power enable fails. The driver then queues
   `restart_work`, clears `force_quit`, and re-enables IRQs — all
   operating under the assumption that hardware is powered.

3. **Scope limiter**: `mcp251x_power_enable()` returns 0 for
   `IS_ERR_OR_NULL(reg)` (verified at line 951), so the bug only
   manifests on systems with real regulator-backed `vdd`/`xceiver`
   supplies.

### Step 2.4: Assess the Fix Quality
Record: The fix is obviously correct — standard error checking and
rollback patterns matching the existing `mcp251x_can_probe()` style
(which already checks `mcp251x_power_enable(priv->power, 1)` at line
1394). The fix is minimal and surgical. Regression risk is extremely low
— only error paths are affected, and those paths were previously broken.
The CAN subsystem maintainer personally modified the patch.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame the Changed Lines
Record: `git blame` confirms:
- Line 1228: unchecked `mcp251x_power_enable(priv->transceiver, 1)` in
  `open()` introduced by commit `1ddff7da0faecf` (Alexander Shiyan,
  2013-08-19, "can: mcp251x: Replace power callbacks with regulator
  API").
- Lines 1520-1523: unchecked enables in `resume()` from `1ddff7da0faecf`
  and `25b401c1816ae6` (Stefan Agner, 2015).
- `git describe --contains 1ddff7da0faecf` → `v3.12-rc1~132^2~209^2~2` —
  the buggy code has been present since kernel v3.12 (2013). This means
  **all active stable trees** contain the buggy code.

### Step 3.2: Follow the Fixes: Tag
Record: No Fixes: tag present. N/A.

### Step 3.3: Check File History for Related Changes
Record: `git log --oneline -20 -- drivers/net/can/spi/mcp251x.c` shows
related commits:
- `e728f444c913a`: "can: mcp251x: fix deadlock in error path of
  mcp251x_open" — this restructured the error path to use `release_irq`
  / deferred `free_irq()`. The candidate patch's new `out_close_candev`
  label is designed to fit this structure.
- `7dd9c26bd6cf6`: earlier deadlock fix for `mcp251x_open`
- `b1a09b63684ce`: "mcp251x_can_probe(): add missing unregister_candev()
  in error path" — another error-path fix in same file

No evidence this patch is part of a multi-patch series. It is
standalone.

### Step 3.4: Check the Author's Other Commits
Record: `git log --oneline --author='Wenyuan Li' -- drivers/net/can/`
shows:
- `de39b9320ab36`: "can: hi311x: hi3110_open(): add check for
  hi3110_power_enable() return value" — the identical class of fix
  applied to a sibling SPI CAN driver. This commit has already been
  backported to stable (confirmed by the `[Upstream commit ...]` marker
  and Sasha Levin's SOB in `git show`). This establishes a clear
  pattern: the author is systematically fixing unchecked power-enable
  returns across CAN SPI drivers, and the maintainer and stable tree are
  accepting them.

### Step 3.5: Check for Dependent/Prerequisite Commits
Record: The `mcp251x_open()` error path structure depends on commit
`e728f444c913a` (which introduced the `release_irq` pattern and the
current `out_close`/`out_free_irq` layout). This prerequisite is present
in the current tree.

For older stable trees (v5.15, v6.1, v6.6), I verified the `open()`
error path still has the older structure (direct `free_irq()` inside
`out_free_irq` without the deferred pattern). The resume-path changes
should apply cleanly to all trees. The open-path portion may need minor
context adaptation on trees without `e728f444c913a`.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.4: Lore Search
Record: Lore.kernel.org is behind anti-bot protection and could not be
accessed. However:
- The CAN subsystem maintainer Marc Kleine-Budde actively edited and
  restructured the patch (documented in commit message), confirming
  hands-on review
- The sibling `hi311x` fix by the same author was accepted and
  backported to stable
- `git log --oneline --grep='mcp251x.*power'` returned no hits —
  confirming no prior fix for this specific issue exists

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
Record: `mcp251x_open()`, `mcp251x_can_resume()`,
`mcp251x_power_enable()`

### Step 5.2: Trace Callers
Record:
- `mcp251x_open()` is registered as `.ndo_open = mcp251x_open` in
  `mcp251x_netdev_ops` (line 1283). Called when user runs `ip link set
  canX up` — standard interface bring-up path.
- `mcp251x_can_resume()` is registered via
  `SIMPLE_DEV_PM_OPS(mcp251x_can_pm_ops, mcp251x_can_suspend,
  mcp251x_can_resume)` (line 1535). Called by PM framework on system
  resume.

### Step 5.3: Trace Callees
Record: `mcp251x_power_enable()` wraps
`regulator_enable()`/`regulator_disable()` (lines 949-958). Returns 0
for NULL/error regulators (limiting scope to real regulator setups).

### Step 5.4: Call Chain Reachability
Record: Both paths are reachable from standard operations:
- `open()`: userspace/admin brings up CAN interface
- `resume()`: PM framework resumes the SPI device after system suspend
Both are realistic, common operations on embedded systems using MCP251x
with regulator-managed power rails.

### Step 5.5: Similar Patterns
Record: The probe function (`mcp251x_can_probe()`) at line 1394 already
properly checks `mcp251x_power_enable(priv->power, 1)` with error
handling. The candidate patch aligns `open()` and `resume()` with this
existing correct pattern. The identical bug in sibling driver `hi311x`
was already fixed (`de39b9320ab36`).

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Does the Buggy Code Exist in Stable Trees?
Record: **Yes.** Verified with `git show
<tag>:drivers/net/can/spi/mcp251x.c | rg 'mcp251x_power_enable'`:
- **v5.15:** unchecked `mcp251x_power_enable(priv->transceiver, 1)` at
  line 1208 (open) and lines 1482-1484 (resume)
- **v6.1:** same at lines 1215, 1491-1493
- **v6.6:** same at lines 1215, 1491-1493

The buggy code was introduced in v3.12 (2013) and is present in **all
active stable trees**.

### Step 6.2: Backport Complications
Record:
- **Resume path:** Should apply cleanly to all stable trees — the code
  structure is essentially identical
- **Open path:** Requires minor adaptation on v5.15/v6.1/v6.6 because
  those trees have the older `mcp251x_open()` error structure (without
  the `release_irq`/deferred `free_irq` pattern from `e728f444c913a`).
  The `out_close_candev` label placement would need adjustment.
- Overall difficulty: **clean for resume; minor conflicts for open**

### Step 6.3: Related Fixes Already in Stable
Record: No existing fix for this specific issue found. `git log
--oneline --grep='mcp251x.*power'` returned no results.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
Record: CAN networking, SPI driver (`drivers/net/can/spi/mcp251x.c`).
Criticality: **IMPORTANT** for embedded/industrial/automotive CAN users.
The MCP2510/MCP2515/MCP25625 are among the most popular SPI CAN
controllers.

### Step 7.2: Subsystem Activity
Record: The file has 20+ recent commits. Active subsystem with ongoing
maintenance (deadlock fixes, probe fixes, etc.). Mature code with the
specific bug present since 2013.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Record: **Driver-specific + config-specific.** Users of MCP251x CAN
controllers with regulator-backed `vdd` and/or `xceiver` supplies.
`mcp251x_power_enable()` returns 0 for `IS_ERR_OR_NULL(reg)`, so systems
without real regulators are unaffected. Typical use case:
embedded/industrial/automotive CAN systems.

### Step 8.2: Trigger Conditions
Record:
- **Open path:** Triggered when transceiver regulator fails to enable
  (hardware fault, supply issue, GPIO unavailability, deferred
  regulator)
- **Resume path:** Triggered when power/transceiver regulator fails
  during system resume (battery issues, regulator constraints)
- These are realistic on embedded systems. Not a constant trigger but a
  real-world scenario.

### Step 8.3: Failure Mode Severity
Record:
- **Kernel WARN() trigger** from regulator framework on the unbalanced
  disable path in `open()` — **MEDIUM** (kernel warning, noisy logs,
  stack trace output)
- **Silent PM resume failure** — PM framework believes success while
  hardware is unpowered — **MEDIUM-HIGH** (restart_work handler performs
  SPI operations on unpowered hardware, device non-functional after
  resume without any error indication)
- **Regulator state corruption** — enable_count imbalance can affect
  future operations — **MEDIUM**

Overall severity: **MEDIUM**

### Step 8.4: Risk-Benefit Ratio
Record:
- **Benefit:** Prevents kernel WARN(), prevents silent resume failures,
  maintains regulator state consistency, aligns with existing probe-path
  error handling. **Moderate-to-high benefit.**
- **Risk:** ~20 lines of standard error handling in one file, only
  affects failure paths that were previously broken, reviewed by
  subsystem maintainer. **Very low risk.**
- **Ratio:** Strongly favorable for backport.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Compile the Evidence

**Evidence FOR backporting:**
- Fixes concrete kernel WARN() trigger (verified: regulator
  `enable_count == 0` → WARN in `drivers/regulator/core.c:3179`)
- Fixes silent PM resume failure (PM framework told success while
  hardware is unpowered)
- Fixes regulator state imbalance (unbalanced disable in error path)
- Small, surgical, single-file fix (~20 lines)
- Reviewed and actively modified by CAN subsystem maintainer Marc
  Kleine-Budde
- Sibling hi311x driver fix by same author already backported to stable
  (`de39b9320ab36`)
- Buggy code present in all stable trees since v3.12 (2013)
- Aligns with existing probe-path error handling pattern in same driver
- Standard error-handling patterns — obviously correct

**Evidence AGAINST backporting:**
- No user-reported crash or syzbot report (found by code inspection)
- Trigger requires regulator-enable failure (specific hardware
  conditions)
- Open-path portion may need minor context adaptation on older stable
  trees
- Severity is MEDIUM, not CRITICAL

**Unresolved:**
- Lore.kernel.org discussion not accessible (anti-bot protection)
- Exact applicability to stable trees older than v5.15 not verified

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — standard error handling,
   maintainer-reviewed and modified
2. **Fixes a real bug?** YES — verified WARN() trigger from regulator
   framework, silent PM resume failure
3. **Important issue?** YES — kernel warning, incorrect PM behavior,
   regulator state corruption (MEDIUM severity)
4. **Small and contained?** YES — ~20 lines in one file, two functions
5. **No new features or APIs?** YES — purely error handling
6. **Can apply to stable trees?** YES for resume path (clean); minor
   adaptation needed for open path on older trees

### Step 9.3: Exception Categories
Record: Not applicable. This is a standard bug fix, not a device ID,
quirk, DT update, build fix, or documentation fix.

### Step 9.4: Decision
The fix addresses verified, concrete bugs (regulator framework WARN
trigger, silent PM resume failure, regulator state corruption), is small
and obviously correct, was reviewed by the subsystem maintainer, and the
identical class of fix for the sibling driver was already backported to
stable. The risk-benefit ratio is strongly favorable. The buggy code has
been present since v3.12 and affects all active stable trees.

---

## Verification

- **[Phase 1]** Parsed all tags from provided commit message: Signed-
  off-by (author + maintainer), Link, maintainer edit notes. No
  Fixes/Reported-by/Cc stable.
- **[Phase 2]** Read current `mcp251x_open()` and `mcp251x_can_resume()`
  in `drivers/net/can/spi/mcp251x.c`; confirmed unchecked
  `mcp251x_power_enable()` calls at lines 1228, 1520-1523
- **[Phase 2]** Read `mcp251x_power_enable()` at lines 949-958;
  confirmed returns 0 for `IS_ERR_OR_NULL(reg)` — bug scope limited to
  real regulator setups
- **[Phase 2]** Verified regulator WARN trigger:
  `drivers/regulator/core.c` line 3179 — `WARN(regulator->enable_count
  == 0, "unbalanced disables for %s\n", ...)` — fires when `out_close`
  calls disable on never-enabled regulator
- **[Phase 2]** Read current error path in `open()` at lines 1260-1279:
  confirmed `out_close` calls `mcp251x_power_enable(priv->transceiver,
  0)` unconditionally
- **[Phase 3]** `git blame -L 1208,1290`: confirmed unchecked
  transceiver enable from `1ddff7da0faecf` (2013-08-19)
- **[Phase 3]** `git blame -L 1500,1560`: confirmed unchecked resume
  enables from `1ddff7da0faecf` and `25b401c1816ae6`
- **[Phase 3]** `git describe --contains 1ddff7da0faecf` →
  `v3.12-rc1~132^2~209^2~2` — buggy code introduced before v3.12
- **[Phase 3]** `git show --stat 1ddff7da0faecf`: confirmed this was the
  regulator API conversion that introduced `mcp251x_power_enable()`
  usage
- **[Phase 3]** `git log --oneline -20 --
  drivers/net/can/spi/mcp251x.c`: confirmed related deadlock fixes
  `e728f444c913a` and `7dd9c26bd6cf6`
- **[Phase 3]** `git log --oneline --author='Wenyuan Li' --
  drivers/net/can/`: found sibling fix `de39b9320ab36` (hi311x)
- **[Phase 3]** `git show de39b9320ab36`: confirmed identical class of
  fix, already backported to stable (has Upstream commit marker and
  Sasha Levin SOB)
- **[Phase 3]** `git log --oneline --grep='mcp251x.*power'`: no prior
  fix for this specific issue exists
- **[Phase 4]** Lore.kernel.org: blocked by anti-bot protection;
  maintainer edits in commit message confirm review
- **[Phase 5]** Verified `mcp251x_open` is `ndo_open` callback (line
  1283); `mcp251x_can_resume` registered via `SIMPLE_DEV_PM_OPS` (line
  1535)
- **[Phase 5]** Confirmed `mcp251x_can_probe()` at line 1394 already
  checks `mcp251x_power_enable(priv->power, 1)` — this fix aligns
  open/resume with probe
- **[Phase 6]** `git show v5.15:drivers/net/can/spi/mcp251x.c | rg
  mcp251x_power_enable`: confirmed unchecked calls exist in v5.15
- **[Phase 6]** `git show v6.1:drivers/net/can/spi/mcp251x.c | rg
  mcp251x_power_enable`: confirmed unchecked calls exist in v6.1
- **[Phase 6]** `git show v6.6:drivers/net/can/spi/mcp251x.c | rg
  mcp251x_power_enable`: confirmed unchecked calls exist in v6.6
- **[Phase 6]** Inspected v5.15 `mcp251x_open()` error path: confirmed
  older structure (direct `free_irq` in `out_free_irq`, no `release_irq`
  pattern) — open-path portion needs minor adaptation for older trees
- **[Phase 6]** Inspected v5.15 `mcp251x_can_resume()`: confirmed
  identical unchecked pattern — resume-path portion should apply cleanly
- **[Phase 8]** Failure mode: regulator WARN() on error path (MEDIUM),
  silent PM resume failure (MEDIUM-HIGH), overall MEDIUM severity
- **UNVERIFIED:** Full lore.kernel.org patch discussion and any explicit
  stable nominations by reviewers (anti-bot blocked). Applicability to
  stable trees older than v5.15.

**YES**

 drivers/net/can/spi/mcp251x.c | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index bb7782582f401..0d0190ae094a1 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -1225,7 +1225,11 @@ static int mcp251x_open(struct net_device *net)
 	}
 
 	mutex_lock(&priv->mcp_lock);
-	mcp251x_power_enable(priv->transceiver, 1);
+	ret = mcp251x_power_enable(priv->transceiver, 1);
+	if (ret) {
+		dev_err(&spi->dev, "failed to enable transceiver power: %pe\n", ERR_PTR(ret));
+		goto out_close_candev;
+	}
 
 	priv->force_quit = 0;
 	priv->tx_skb = NULL;
@@ -1272,6 +1276,7 @@ static int mcp251x_open(struct net_device *net)
 	mcp251x_hw_sleep(spi);
 out_close:
 	mcp251x_power_enable(priv->transceiver, 0);
+out_close_candev:
 	close_candev(net);
 	mutex_unlock(&priv->mcp_lock);
 	if (release_irq)
@@ -1516,11 +1521,25 @@ static int __maybe_unused mcp251x_can_resume(struct device *dev)
 {
 	struct spi_device *spi = to_spi_device(dev);
 	struct mcp251x_priv *priv = spi_get_drvdata(spi);
+	int ret = 0;
 
-	if (priv->after_suspend & AFTER_SUSPEND_POWER)
-		mcp251x_power_enable(priv->power, 1);
-	if (priv->after_suspend & AFTER_SUSPEND_UP)
-		mcp251x_power_enable(priv->transceiver, 1);
+	if (priv->after_suspend & AFTER_SUSPEND_POWER) {
+		ret = mcp251x_power_enable(priv->power, 1);
+		if (ret) {
+			dev_err(dev, "failed to restore power: %pe\n", ERR_PTR(ret));
+			return ret;
+		}
+	}
+
+	if (priv->after_suspend & AFTER_SUSPEND_UP) {
+		ret = mcp251x_power_enable(priv->transceiver, 1);
+		if (ret) {
+			dev_err(dev, "failed to restore transceiver power: %pe\n", ERR_PTR(ret));
+			if (priv->after_suspend & AFTER_SUSPEND_POWER)
+				mcp251x_power_enable(priv->power, 0);
+			return ret;
+		}
+	}
 
 	if (priv->after_suspend & (AFTER_SUSPEND_POWER | AFTER_SUSPEND_UP))
 		queue_work(priv->wq, &priv->restart_work);
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk

[Sasha Levin]

From: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>

[ Upstream commit faceb5cf5d7a08f4a40335d22d833bb75f05d99e ]

HP Laptop 15-fd0xxx with ALC236 codec does not handle the toggling of
the mute LED.
This patch adds a quirk entry for subsystem ID 0x8dd7 using
ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED
behavior.

Signed-off-by: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>
Link: https://patch.msgid.link/DHAB51ISUM96.2K9SZIABIDEQ0@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the facts needed. Here is my comprehensive answer:

---

## Phase 1: Commit Message Forensics

**Step 1.1: Parse the Subject Line**
Record: [ALSA: hda/realtek] [add] [HP Laptop 15-fd0xxx mute LED quirk —
adds SND_PCI_QUIRK entry for subsystem ID 0x103c:0x8dd7 using existing
ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup]

**Step 1.2: Parse All Commit Message Tags**
Record:
- `Signed-off-by: Kshamendra Kumar Mishra
  <kshamendrakumarmishra@gmail.com>` — author
- `Link: https://patch.msgid.link/DHAB51ISUM96.2K9SZIABIDEQ0@gmail.com`
  — patch submission reference
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>` — ALSA subsystem
  maintainer
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable@vger.kernel.org` (expected for manual review
  candidates)

**Step 1.3: Analyze the Commit Body Text**
Record: Bug: HP Laptop 15-fd0xxx with ALC236 codec does not handle mute
LED toggling. Symptom: Mute LED does not reflect mute state. Root cause:
Missing SSID-to-fixup mapping in the quirk table. Fix: Add entry for
subsystem ID 0x8dd7 pointing to existing
`ALC236_FIXUP_HP_MUTE_LED_COEFBIT2`.

**Step 1.4: Detect Hidden Bug Fixes**
Record: Not a hidden bug fix — this is an explicit hardware quirk
addition. The message directly describes a non-working mute LED and the
fixup that corrects it.

## Phase 2: Diff Analysis

**Step 2.1: Inventory the Changes**
Record: `sound/hda/codecs/realtek/alc269.c`: +1 line, -0 lines. Single
`SND_PCI_QUIRK` entry added to `alc269_fixup_tbl[]` between existing
entries 0x8dd4 and 0x8de8. Scope: single-file, single-line, table-data-
only.

**Step 2.2: Understand the Code Flow Change**
Record: Before: No quirk entry for 0x103c:0x8dd7; `snd_hda_pick_fixup()`
cannot select `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` for this machine, so
the mute LED is not properly controlled. After: The SSID match triggers
the existing fixup during codec probe, enabling correct mute LED
behavior.

**Step 2.3: Identify the Bug Mechanism**
Record: Bug category: Hardware workaround / missing quirk entry. The
`alc236_fixup_hp_mute_led_coefbit2()` helper programs
`spec->mute_led_coef.idx = 0x07`, `mask = 1`, `on = 1`, `off = 0` and
registers `coef_mute_led_set` via `snd_hda_gen_add_mute_led_cdev()`.
This is an existing, well-tested code path used by 17 other entries in
this file.

**Step 2.4: Assess the Fix Quality**
Record: Obviously correct — identical pattern to many existing HP ALC236
quirk entries. Minimal and surgical. Regression risk is effectively zero
since the new entry only matches one specific subsystem ID and uses an
existing, well-exercised fixup chain.

## Phase 3: Git History Investigation

**Step 3.1: Blame the Changed Lines**
Record: The neighboring entries (0x8dd4 at line 7099, 0x8de8 at line
7100) confirm the correct insertion point. The new 0x8dd7 entry is not
present in the current tree (verified by grep).

**Step 3.2: Follow the Fixes Tag**
Record: N/A — no `Fixes:` tag present.

**Step 3.3: Check File History for Related Changes**
Record: Recent `alc269.c` history shows a steady stream of similar
Realtek quirk additions (Acer, Samsung, HP models). This is a standalone
one-line addition — no patch series marker found.

**Step 3.4: Check the Author's Other Commits**
Record: The accepting maintainer is Takashi Iwai (`tiwai@suse.de`), the
long-standing ALSA maintainer, providing strong endorsement of this
quirk.

**Step 3.5: Check for Dependent/Prerequisite Commits**
Record: The prerequisite helper `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` was
introduced by commit `0659400f18c0e6` ("ALSA: hda/realtek: Enable Mute
LED on HP Laptop 15s-eq2xxx") which first appeared in `v6.5`. That
commit itself had `Cc: stable@vger.kernel.org`. The helper exists in
v6.5+, v6.6, and v6.19. It does **not** exist in v6.1 or v5.15.

## Phase 4: Mailing List and External Research

**Step 4.1: Search Lore**
Record: The `patch.msgid.link` URL returned an anti-bot page. Could not
retrieve the actual patch discussion thread. UNVERIFIED: exact reviewer
comments or stable nominations.

**Step 4.2: Search for Bug Report**
Record: No `Reported-by:` or bugzilla link. The only bug description is
in the commit message itself.

**Step 4.3: Check for Related Patches**
Record: This is a standalone single-line quirk addition, not part of a
multi-patch series.

**Step 4.4: Check Stable Mailing List**
Record: Similar HP Realtek mute LED quirks have been backported to
stable before (e.g., the original `0659400f18c0e6` helper commit had
`Cc: stable`). No specific stable discussion found for this exact patch.

## Phase 5: Code Semantic Analysis

**Step 5.1: Key Functions**
Record: No function body is modified. The change is data-only in
`alc269_fixup_tbl[]`. The affected runtime function is the existing
`alc236_fixup_hp_mute_led_coefbit2()`.

**Step 5.2: Trace Callers**
Record: `alc269_fixup_tbl[]` → consumed by `snd_hda_pick_fixup()` called
from `alc269_probe()` → registered as `.probe` in `alc269_codec_ops` /
`alc269_driver` via `module_hda_codec_driver()`. The fixup runs at codec
probe time on matching hardware.

**Step 5.3: Trace Callees**
Record: `alc236_fixup_hp_mute_led_coefbit2()` sets `spec->mute_led_coef`
fields and calls `snd_hda_gen_add_mute_led_cdev(codec,
coef_mute_led_set)`. `coef_mute_led_set()` calls
`alc_update_coef_led()`. This only affects LED control, not audio
routing or codec initialization logic.

**Step 5.4: Call Chain Reachability**
Record: HDA codec probe → `alc269_probe()` → `snd_hda_pick_fixup(...
alc269_fixup_tbl ...)` → `snd_hda_apply_fixup(HDA_FIXUP_ACT_PRE_PROBE)`
→ `alc236_fixup_hp_mute_led_coefbit2()`. Reachable only on systems with
the exact matching subsystem ID.

**Step 5.5: Similar Patterns**
Record: `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` appears 17 times in
`alc269.c`, confirming it is a well-established fixup used by many HP
devices. Related one-line commits include `d510acb610e6aa`,
`d33c3471047fc`, `9ed7a28225af0`.

## Phase 6: Stable Tree Analysis

**Step 6.1: Does the Buggy Code Exist in Stable Trees?**
Record: The missing quirk (0x8dd7 absent) affects any stable tree that
carries the `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` helper. Verified:
- **v6.19**: helper present in `sound/hda/codecs/realtek/alc269.c` —
  **applicable**
- **v6.6**: helper present in `sound/pci/hda/patch_realtek.c` (5
  occurrences) — **applicable** (minor path adjustment needed)
- **v6.1**: helper **absent** (0 occurrences) — **not standalone
  applicable**
- **v5.15**: helper **absent** (0 occurrences) — **not standalone
  applicable**

**Step 6.2: Backport Complications**
Record: For v6.19.y: clean apply expected (same file layout). For
v6.6.y: needs minor mechanical adjustment (file is
`sound/pci/hda/patch_realtek.c` instead of the new split path, and
different surrounding context lines). For v6.1.y and v5.15.y: not a
standalone backport — prerequisite infrastructure absent.

**Step 6.3: Related Fixes Already in Stable**
Record: The original helper commit `0659400f18c0e6` had `Cc:
stable@vger.kernel.org` and is present from v6.5 onward. The exact
0x8dd7 entry is not yet present anywhere (verified by grep).

## Phase 7: Subsystem and Maintainer Context

**Step 7.1: Subsystem Criticality**
Record: ALSA HDA Realtek codec driver — IMPORTANT level for affected
laptop users. Not core kernel, but real user-visible hardware
functionality.

**Step 7.2: Subsystem Activity**
Record: Highly active — frequent quirk additions and fixes to
`alc269.c`, typical for ongoing hardware enablement.

## Phase 8: Impact and Risk Assessment

**Step 8.1: Who Is Affected**
Record: Users of HP Laptop 15-fd0xxx with ALC236 codec and subsystem ID
0x103c:0x8dd7. Driver-specific, hardware-specific.

**Step 8.2: Trigger Conditions**
Record: Every time the user mutes/unmutes audio, the LED does not
correctly reflect the mute state. Affects normal daily use of the
laptop.

**Step 8.3: Failure Mode Severity**
Record: Mute LED does not toggle — user cannot visually confirm mute
state. Severity: LOW-MEDIUM (hardware not working as designed, but no
crash/corruption/security issue).

**Step 8.4: Risk-Benefit Ratio**
Record: Benefit: Restores expected mute LED behavior for a specific HP
laptop model. Risk: Effectively zero — one table entry matching a single
subsystem ID, using an existing well-tested fixup chain. Ratio: Very
favorable.

## Phase 9: Final Synthesis

**Step 9.1: Compile the Evidence**

Evidence FOR backporting:
- Single-line hardware quirk addition — explicit exception category for
  stable
- Uses existing, well-tested fixup (`ALC236_FIXUP_HP_MUTE_LED_COEFBIT2`,
  used by 17 other entries)
- Zero regression risk (only matches one specific hardware subsystem ID)
- Accepted by ALSA maintainer Takashi Iwai
- Fixes real, user-visible hardware behavior for a shipping laptop model
- The original helper commit had `Cc: stable@vger.kernel.org` — the
  infrastructure was intended for stable

Evidence AGAINST backporting:
- Low severity (LED behavior only, not crash/security/corruption)
- Not standalone for v6.1.y and v5.15.y (helper absent)

Unresolved:
- Exact mailing list review discussion (blocked by Anubis)
- Independent testing beyond author and maintainer signoff

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — identical pattern to 17
   existing entries using the same fixup
2. Fixes a real bug? **YES** — mute LED non-functional on specific
   hardware
3. Important issue? **MEDIUM** — hardware not working as expected; fits
   the quirk exception
4. Small and contained? **YES** — 1 line in 1 file
5. No new features or APIs? **YES** — uses existing fixup
6. Can apply to stable? **YES** for v6.6.y and v6.19.y; **NO** as
   standalone for v6.1.y/v5.15.y

**Step 9.3: Exception Category**
Record: **Audio codec quirk** (`SND_PCI_QUIRK` entry for existing fixup)
— explicitly listed as an allowed exception for stable backporting.

**Step 9.4: Decision**
This is a textbook hardware quirk addition: one line, zero regression
risk, existing infrastructure, maintainer-accepted. It should be
backported to stable trees that already contain the
`ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` helper (v6.6.y and newer).

## Verification

- [Phase 1] Parsed tags: `Signed-off-by` from author and ALSA maintainer
  Takashi Iwai; `Link:` to patch submission; no `Fixes:`, `Reported-
  by:`, or `Cc: stable`
- [Phase 2] Diff analysis: +1 line `SND_PCI_QUIRK(0x103c, 0x8dd7, ...)`
  in `alc269_fixup_tbl[]`; verified 0x8dd7 not present in current tree
  (grep returned no matches)
- [Phase 2] Read `alc236_fixup_hp_mute_led_coefbit2()` at lines
  1525-1538: confirmed it sets `mute_led_coef.idx = 0x07`, `mask = 1`,
  `on = 1`, `off = 0` and calls `snd_hda_gen_add_mute_led_cdev()`
- [Phase 2] Verified 17 occurrences of
  `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` in `alc269.c` — well-established
  fixup
- [Phase 3] `git log -S'ALC236_FIXUP_HP_MUTE_LED_COEFBIT2'` confirmed
  introduction by `0659400f18c0e6` and subsequent quirk additions
- [Phase 3] `git show 0659400f18c0e6`: confirmed helper introduction
  with `Cc: <stable@vger.kernel.org>`
- [Phase 3] `git tag --contains 0659400f18c0e6`: helper first appeared
  in v6.5 lineage
- [Phase 3] Verified insertion point: 0x8dd4 at line 7099, 0x8de8 at
  line 7100 — correct sorted position
- [Phase 4] `patch.msgid.link` URL blocked by anti-bot protection —
  UNVERIFIED: reviewer comments
- [Phase 5] Traced call chain: `alc269_probe()` → `snd_hda_pick_fixup()`
  → `snd_hda_apply_fixup()` → helper. Probe-time only.
- [Phase 6] **v6.6**: `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` present (5
  occurrences in `patch_realtek.c`) — applicable
- [Phase 6] **v6.1**: helper absent (0 occurrences) — NOT standalone
  applicable
- [Phase 6] **v5.15**: helper absent (0 occurrences) — NOT standalone
  applicable
- [Phase 8] Failure mode: non-functional mute LED only; severity LOW-
  MEDIUM; no crash/security/data path
- UNVERIFIED: exact mailing list discussion content and any external
  test reports for this specific model

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 5adc5db6fd52b..1054191d56fa1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7099,6 +7099,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8da7, "HP 14 Enstrom OmniBook X", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8da8, "HP 16 Piston OmniBook X", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8dd4, "HP EliteStudio 8 AIO", ALC274_FIXUP_HP_AIO_BIND_DACS),
+	SND_PCI_QUIRK(0x103c, 0x8dd7, "HP Laptop 15-fd0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
 	SND_PCI_QUIRK(0x103c, 0x8de8, "HP Gemtree", ALC245_FIXUP_TAS2781_SPI_2),
 	SND_PCI_QUIRK(0x103c, 0x8de9, "HP Gemtree", ALC245_FIXUP_TAS2781_SPI_2),
 	SND_PCI_QUIRK(0x103c, 0x8dec, "HP EliteBook 640 G12", ALC236_FIXUP_HP_GPIO_LED),
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.6] ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC

[Sasha Levin]

From: Matthew Schwartz <matthew.schwartz@linux.dev>

[ Upstream commit 59f68dc1d8df3142cb58fd2568966a9bb7b0ed8a ]

Fixes lack of audio output on the ASUS ROG Flow Z13-KJP GZ302EAC model,
similar to the ASUS ROG Flow Z13 GZ302EA.

Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260313172503.285846-1-matthew.schwartz@linux.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: No function bodies modified. The change is purely data — one
entry in the `alc269_fixup_tbl[]` static quirk table.

**Step 5.2: TRACE CALLERS**
Record: `alc269_fixup_tbl[]` is consumed by `snd_hda_pick_fixup()`
during `alc269_probe()`, which is the `.probe` callback in
`alc269_codec_ops`. This runs during HDA codec initialization — a
standard device-probe path.

**Step 5.3: TRACE CALLEES**
Record: `[ALC287_FIXUP_CS35L41_I2C_2]` at line 6200 maps to
`cs35l41_fixup_i2c_two()` (line 3231), which calls
`comp_generic_fixup(cdc, action, "i2c", "CSC3551",
"-%s:00-cs35l41-hda.%d", 2)` — initializing two CS35L41 companion
amplifiers over I2C.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: HDA codec driver registration → `alc269_probe()` →
`snd_hda_pick_fixup(... alc269_fixup_tbl ...)` → SSID match selects
fixup → `snd_hda_apply_fixup(HDA_FIXUP_ACT_PRE_PROBE)` →
`cs35l41_fixup_i2c_two()` → `comp_generic_fixup()` →
`hda_component_manager_init()` for two CSC3551 amps. This is reached
automatically during boot on affected hardware — not an obscure or debug
path.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: `ALC287_FIXUP_CS35L41_I2C_2` appears 113 times in this file. The
sibling ASUS ROG Flow Z13 GZ302EA at line 7284 uses the exact same fixup
(`0x1043:0x1fb3 → ALC287_FIXUP_CS35L41_I2C_2`). This is a thoroughly
proven pattern.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
Record: Verified via `git grep`:
- **v6.6**: `ALC287_FIXUP_CS35L41_I2C_2` exists in
  `sound/pci/hda/patch_realtek.c` — applicable
- **v6.1**: `ALC287_FIXUP_CS35L41_I2C_2` exists in
  `sound/pci/hda/patch_realtek.c` — applicable
- **v5.15**: `ALC287_FIXUP_CS35L41_I2C_2` does NOT exist — **not
  applicable** without prerequisite work

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: Mainline has moved the code from `sound/pci/hda/patch_realtek.c`
to `sound/hda/codecs/realtek/alc269.c` (file split). Backports to v6.6
and v6.1 will need a trivial path adjustment. The actual change is still
a single `SND_PCI_QUIRK` line insertion in the same quirk table — only
context lines and file path differ. Expected difficulty:
**minor/trivial**.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE**
Record: The `0x1514` SSID entry does not exist in the current tree
(confirmed by grep). The sibling `0x1fb3` (GZ302EA) commit
`12784ca33b62f` is also not in v6.6, v6.1, or v5.15.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: Subsystem: sound/HDA/Realtek codec. Criticality: IMPORTANT —
audio is a core laptop function. While hardware-specific, this affects
all users of this specific ASUS model.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Highly active — the recent 20 commits are exclusively quirk
additions and small fixes. This is normal and expected for the Realtek
HDA quirk table.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Owners of ASUS ROG Flow Z13-KJP GZ302EAC laptops using in-kernel
HDA Realtek audio. Hardware-specific / driver-specific population.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Every boot — the missing quirk causes incorrect codec
initialization automatically during probe. No special user action
required. Deterministic on affected hardware.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Complete lack of audio output on the affected laptop. Severity:
**HIGH** for affected users — a core hardware function
(speakers/headphones) is entirely non-functional. Not a crash or
security issue, but a complete functional failure of essential hardware.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit**: HIGH for affected users — restores audio functionality on
  a real, shipping laptop
- **Risk**: NEAR-ZERO — one line, SSID-gated (only matches
  0x1043:0x1514), reuses a well-established fixup used by 113 entries
- **Ratio**: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

Evidence FOR backporting:
- Fixes complete lack of audio output on a real shipping laptop
- Falls into the explicit "Audio Codec Quirks" exception category —
  automatic YES
- One line added — minimal possible change
- Uses existing, heavily-tested fixup (`ALC287_FIXUP_CS35L41_I2C_2`, 113
  occurrences)
- Sibling model (GZ302EA) uses identical fixup, establishing the pattern
- Accepted by subsystem maintainer Takashi Iwai
- Included in the sound fixes pull for 7.0-rc6
- Applicable to v6.6 and v6.1 stable trees (prerequisite support
  verified)

Evidence AGAINST backporting:
- Not applicable to v5.15 (missing prerequisite fixup infrastructure)
- File path has changed between mainline and stable (minor backport
  friction)
- No explicit Tested-by in this commit (though the sibling commit
  `12784ca33b62f` had one)

Unresolved:
- Takashi Iwai's exact reply content (could not fetch)
- Whether any stable reviewer has already discussed this patch

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. **Obviously correct and tested?** YES — trivial table entry matching
   established pattern, maintainer-accepted
2. **Fixes a real bug that affects users?** YES — no audio output on
   affected hardware
3. **Important issue?** YES — total loss of audio on a laptop
4. **Small and contained?** YES — 1 line, 1 file, data-only change
5. **No new features or APIs?** YES — quirk table entry only, no
   behavioral changes outside targeted SSID
6. **Can apply to stable trees?** YES for v6.1+ and v6.6+ (with path
   adjustment); NO for v5.15

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: **Hardware quirk / Audio Codec Quirk** — `SND_PCI_QUIRK` entry
in the Realtek HDA codec quirk table. This is explicitly in the
automatic YES exception category.

**Step 9.4: MAKE YOUR DECISION**
This is a textbook stable backport candidate. It is a single-line audio
codec quirk addition that restores audio output on a specific ASUS
laptop model using an existing, widely-deployed fixup. It carries near-
zero regression risk and falls squarely into the hardware quirk
exception category.

## Verification

- [Phase 1] Parsed subject/body/tags from the provided commit message;
  found Signed-off-by (author + maintainer) and Link; no Fixes/Reported-
  by/Cc:stable — expected
- [Phase 2] Diff is exactly +1 line: `SND_PCI_QUIRK(0x1043, 0x1514,
  "ASUS ROG Flow Z13 GZ302EAC", ALC287_FIXUP_CS35L41_I2C_2)`
- [Phase 2] Confirmed `ALC287_FIXUP_CS35L41_I2C_2` appears 113 times in
  `alc269.c` — well-established fixup
- [Phase 3] `grep -n '0x1514'` returned no matches — SSID not yet in
  tree
- [Phase 3] `grep -n '0x1fb3'` confirmed sibling GZ302EA at line 7284
  uses identical fixup
- [Phase 3] `git log --follow -S'0x1fb3'` traced sibling to commit
  `12784ca33b62f` ("Fix Asus Z13 2025 audio")
- [Phase 3] `git show 12784ca33b62f` confirmed it adds 0x1043:0x1fb3 →
  ALC287_FIXUP_CS35L41_I2C_2, with Tested-by tag
- [Phase 3] `git log --author="Matthew Schwartz" -10 -- sound/` found
  one related commit (`b7e26c8bdae70`)
- [Phase 4] yhbt.net mirror confirmed standalone [PATCH] posted
  2026-03-13, Takashi Iwai replied 2026-03-14, included in sound fixes
  pull 2026-03-27
- [Phase 4] lore.kernel.org blocked by Anubis; used yhbt.net mirror as
  alternative
- [Phase 5] Verified `[ALC287_FIXUP_CS35L41_I2C_2]` at line 6200 maps to
  `cs35l41_fixup_i2c_two()` → `comp_generic_fixup(... "i2c", "CSC3551",
  ..., 2)`
- [Phase 5] Traced call chain: `alc269_probe()` → `snd_hda_pick_fixup()`
  → `snd_hda_apply_fixup()` → `cs35l41_fixup_i2c_two()`
- [Phase 6] `git grep` against v6.6: `ALC287_FIXUP_CS35L41_I2C_2`
  present in `sound/pci/hda/patch_realtek.c`
- [Phase 6] `git grep` against v6.1: `ALC287_FIXUP_CS35L41_I2C_2`
  present in `sound/pci/hda/patch_realtek.c`
- [Phase 6] `git grep` against v5.15: `ALC287_FIXUP_CS35L41_I2C_2`
  **absent** — not applicable to this tree
- [Phase 6] Identified file path change: mainline uses
  `sound/hda/codecs/realtek/alc269.c`, stable uses
  `sound/pci/hda/patch_realtek.c`
- [Phase 8] Failure mode: complete loss of audio output — severity HIGH
  for affected hardware users
- UNVERIFIED: Exact content of Takashi Iwai's reply (message not
  fetchable from mirrors)
- UNVERIFIED: Whether stable mailing list has prior discussion of this
  specific commit

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index b83f0c4bec142..75f880efdeaf1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7206,6 +7206,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1043, 0x14e3, "ASUS G513PI/PU/PV", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x14f2, "ASUS VivoBook X515JA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1043, 0x1503, "ASUS G733PY/PZ/PZV/PYV", ALC287_FIXUP_CS35L41_I2C_2),
+	SND_PCI_QUIRK(0x1043, 0x1514, "ASUS ROG Flow Z13 GZ302EAC", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
 	SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC),
-- 
2.53.0