[PATCH AUTOSEL 7.0-6.6] docs: cgroup-v1: Update charge-commit section

[PATCH AUTOSEL 7.0-6.6] docs: cgroup-v1: Update charge-commit section

[Sasha Levin]

From: "T.J. Mercier" <tjmercier@google.com>

[ Upstream commit d8769544bde51b0ac980d10f8fe9f9fed6c95995 ]

Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb
try-commit-cancel protocol") removed mem_cgroup_commit_charge() and
mem_cgroup_cancel_charge(), but the docs still refer to those functions.
There is no longer any charge cancellation.

Update the docs to match the code.

Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Tejun Heo <tj@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: subsystem `docs: cgroup-v1`; action verb `Update`;
intent: update `Documentation/admin-guide/cgroup-v1/memcg_test.rst` so
the charge-commit section matches current memcg code.

Step 1.2 Record: tags present: `Signed-off-by: T.J. Mercier
<tjmercier@google.com>` and `Signed-off-by: Tejun Heo <tj@kernel.org>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags in the committed message.

Step 1.3 Record: the body says commit `1d8f136a421f` removed
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, while the
cgroup-v1 memcg docs still name them and describe cancellation.
Symptom/failure mode: incorrect documentation only. Version information:
the referenced removal commit is from 2025-01-13 in the local object
database; candidate commit is from 2026-04-30. Root cause: docs were not
updated when the code was changed.

Step 1.4 Record: this is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `Documentation/admin-
guide/cgroup-v1/memcg_test.rst`, `2 insertions(+), 4 deletions(-)`. No
functions modified. Scope: single-file documentation-only surgical
change.

Step 2.2 Record: before, the section was titled `charge-commit-cancel`,
listed `mem_cgroup_commit_charge()` or `mem_cgroup_cancel_charge()`, and
described `cancel()`. After, it is titled `charge-commit`, lists
`commit_charge()`, and removes the cancellation text.

Step 2.3 Record: bug category is documentation/comment correctness.
Specific mechanism: removes stale references to APIs that are absent in
current `6.19.y`/`7.0.y` code and in `origin/master`.

Step 2.4 Record: fix quality is obviously correct for trees whose memcg
code no longer has `mem_cgroup_commit_charge()` /
`mem_cgroup_cancel_charge()`. Regression risk is zero runtime risk, but
there is a branch-selection concern: `stable/linux-6.12.y` still
contains those functions, so this exact doc update would be misleading
there.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` before the candidate shows the stale doc
lines came from `f3f5edc5e41e` in this repository’s history. `git blame
origin/master` shows the changed lines attributed to `d8769544bde51`.

Step 3.2 Record: no `Fixes:` tag. I still inspected referenced commit
`1d8f136a421f26747e58c01281cba5bffae8d289`; it removed prototypes and
implementations for `mem_cgroup_commit_charge()`,
`mem_cgroup_cancel_charge()`, and related hugetlb try/commit/cancel
helpers.

Step 3.3 Record: recent history for `Documentation/admin-
guide/cgroup-v1/memcg_test.rst` on `origin/master` has only the file
introduction/import commit and this candidate. Related path history
shows the candidate was merged via `cgroup-for-7.1-rc2-fixes`. No
prerequisite doc series found.

Step 3.4 Record: author `T.J. Mercier` has at least one other cgroup-
related commit in `origin/master`; Tejun Heo is listed in `MAINTAINERS`
as cgroup maintainer and committed the patch.

Step 3.5 Record: no code dependencies for the patch itself. It can apply
standalone to the current `stable/linux-7.0.y` checkout. Applicability
must be gated by whether the target tree’s code has removed the old
APIs.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c d8769544bde51...` found the original
submission at
`https://patch.msgid.link/20260430201142.240387-1-tjmercier@google.com`.
`b4 dig -a` found only v1 of a single-patch series. The mbox contains
Tejun’s reply: “Applied to cgroup/for-7.1-fixes.” No NAKs or concerns
found in the saved thread.

Step 4.2 Record: `b4 dig -w` shows recipients included cgroup
maintainers/list and docs list: `tj@kernel.org`, `hannes@cmpxchg.org`,
`mkoutny@suse.com`, `cgroups@vger.kernel.org`, `corbet@lwn.net`,
`skhan@linuxfoundation.org`, `linux-doc@vger.kernel.org`, `linux-
kernel@vger.kernel.org`.

Step 4.3 Record: no `Reported-by` or bug-report `Link:` tags. No syzbot,
bugzilla, or user-impact bug report applies.

Step 4.4 Record: b4 found a standalone single-patch series, not part of
a multi-patch dependency chain.

Step 4.5 Record: web search did not find stable-list discussion for this
exact patch. `WebFetch` to lore/patch.msgid was blocked by Anubis, but
b4 successfully fetched the mbox.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: no functions modified by the diff.

Step 5.2 Record: no callers affected by the diff. For documentation
accuracy, I verified current `stable/linux-7.0.y` code has
`commit_charge()` callers in `charge_memcg()`,
`mem_cgroup_replace_folio()`, and `mem_cgroup_migrate()`.

Step 5.3 Record: no changed callees. The relevant current code has
`commit_charge()` assigning `folio->memcg_data`, and callers also invoke
`memcg1_commit_charge()` where appropriate.

Step 5.4 Record: runtime reachability is not relevant because no
executable code changes.

Step 5.5 Record: similar stale docs pattern exists in stable branches;
however code state differs by branch. `6.19.y`/`7.0.y` have stale docs
and no old API. `6.12.y` still has `mem_cgroup_commit_charge()` and
`mem_cgroup_cancel_charge()` in code.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy stale documentation exists in
`stable/linux-7.0.y`, `stable/linux-6.19.y`, `stable/linux-6.18.y`,
`stable/linux-6.6.y`, `stable/linux-6.1.y`, `stable/linux-5.15.y`, and
`stable/linux-5.10.y` by exact doc grep. I verified the old APIs are
absent in several of those trees, but `stable/linux-6.12.y` still
contains `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`,
so this exact upstream text is not universally correct for all
maintained stable lines.

Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `stable/linux-7.0.y` checkout. Expected backport difficulty:
clean for trees with matching doc context; branch-specific review needed
for `6.12.y`.

Step 6.3 Record: no related stable fix for this exact doc update found
by local stable branch ancestry checks or web search.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is cgroup-v1 memcg documentation.
Criticality: peripheral/runtime-none; important only for documentation
correctness.

Step 7.2 Record: cgroup and memcg areas are active; recent
`origin/master` history includes multiple cgroup/mm fixes. The candidate
was applied by the cgroup maintainer.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is documentation readers and
developers/admins consulting old cgroup-v1 memcg internals. No kernel
runtime users are affected.

Step 8.2 Record: trigger condition is reading or relying on the stale
documentation. Unprivileged users cannot trigger a kernel failure
because there is no runtime behavior.

Step 8.3 Record: failure mode is incorrect documentation. Severity: LOW.
It can mislead developers/admins, but it does not fix crash, corruption,
leak, deadlock, or security behavior.

Step 8.4 Record: benefit is low but real for documentation correctness,
especially because the stable rules exception allows
documentation/comment fixes and runtime risk is zero. Risk is very low
for branches whose code matches the new text; risk is documentation-
regression risk if applied to a branch like `6.12.y` where cancellation
APIs still exist.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: tiny docs-only patch;
corrects verified stale references in current `7.0.y` and `6.19.y`;
applied by cgroup maintainer; no runtime regression risk; documentation
fixes are allowed. Evidence against: no runtime bug or user-visible
stability issue; not correct for every stable branch, specifically
verified `6.12.y` still has the old commit/cancel APIs. Unresolved: I
did not exhaustively validate every maintained stable branch’s memcg API
state.

Step 9.2 Stable rules checklist:
1. Obviously correct and tested? Yes for matching-code branches;
   verified by code grep, `git diff --check`, and `git apply --check` on
   `7.0.y`.
2. Fixes a real bug that affects users? It fixes incorrect
   documentation, not runtime behavior.
3. Important issue? No runtime severity; LOW documentation correctness
   issue.
4. Small and contained? Yes, 6-line docs-only diff in one file.
5. No new features or APIs? Yes.
6. Can apply to stable trees? Yes to at least current `7.0.y`; should
   not be applied blindly to `6.12.y`.

Step 9.3 Record: exception category is documentation fix.

Step 9.4 Decision: backport is acceptable for stable trees whose memcg
implementation no longer has charge cancellation APIs. It should be
excluded from trees like `6.12.y` where the old APIs still exist. With
that branch-selection caveat, this qualifies under the documentation-fix
exception.

Verification:
- [Phase 1] Parsed candidate commit
  `d8769544bde51b0ac980d10f8fe9f9fed6c95995`: only two Signed-off-by
  tags, no bug/report/stable tags.
- [Phase 2] `git show --stat --patch`: confirmed one docs file, `2
  insertions(+), 4 deletions(-)`.
- [Phase 3] `git show 1d8f136a421f...`: confirmed referenced commit
  removed `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`
  from mainline code.
- [Phase 3] `git log origin/master --grep`: found candidate and merge
  via `cgroup-for-7.1-rc2-fixes`.
- [Phase 4] `b4 dig`: found lore thread and exact patch-id match.
- [Phase 4] `b4 dig -a`: only v1 single-patch series.
- [Phase 4] `b4 dig -w`: relevant cgroup and docs maintainers/lists were
  included.
- [Phase 4] Saved mbox: confirmed Tejun replied “Applied to
  cgroup/for-7.1-fixes”; no NAKs or stable nomination found.
- [Phase 5] `rg`/`git grep`: confirmed current code uses
  `commit_charge()` and no longer has old API names in `7.0.y`.
- [Phase 6] `git apply --check`: candidate applies cleanly to current
  `7.0.y`.
- [Phase 6] Branch checks: `6.12.y` still has
  `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, so this
  patch must not be applied there unchanged.
- [Phase 8] Runtime impact verified as none because only
  `Documentation/admin-guide/cgroup-v1/memcg_test.rst` changes.

**YES**

 Documentation/admin-guide/cgroup-v1/memcg_test.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 9f8e27355cba5..7c7cd457cf695 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -47,21 +47,19 @@ Please note that implementation details can be changed.
 	  Called when swp_entry's refcnt goes down to 0. A charge against swap
 	  disappears.
 
-3. charge-commit-cancel
+3. charge-commit
 =======================
 
 	Memcg pages are charged in two steps:
 
 		- mem_cgroup_try_charge()
-		- mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
+		- commit_charge()
 
 	At try_charge(), there are no flags to say "this page is charged".
 	at this point, usage += PAGE_SIZE.
 
 	At commit(), the page is associated with the memcg.
 
-	At cancel(), simply usage -= PAGE_SIZE.
-
 Under below explanation, we assume CONFIG_SWAP=y.
 
 4. Anonymous
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] docs: cgroup-v1: Update charge-commit section

[Sasha Levin]

From: "T.J. Mercier" <tjmercier@google.com>

[ Upstream commit d8769544bde51b0ac980d10f8fe9f9fed6c95995 ]

Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb
try-commit-cancel protocol") removed mem_cgroup_commit_charge() and
mem_cgroup_cancel_charge(), but the docs still refer to those functions.
There is no longer any charge cancellation.

Update the docs to match the code.

Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Tejun Heo <tj@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: subsystem `docs: cgroup-v1`; action verb `Update`;
intent: update `Documentation/admin-guide/cgroup-v1/memcg_test.rst` so
the charge-commit section matches current memcg code.

Step 1.2 Record: tags present: `Signed-off-by: T.J. Mercier
<tjmercier@google.com>` and `Signed-off-by: Tejun Heo <tj@kernel.org>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags in the committed message.

Step 1.3 Record: the body says commit `1d8f136a421f` removed
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, while the
cgroup-v1 memcg docs still name them and describe cancellation.
Symptom/failure mode: incorrect documentation only. Version information:
the referenced removal commit is from 2025-01-13 in the local object
database; candidate commit is from 2026-04-30. Root cause: docs were not
updated when the code was changed.

Step 1.4 Record: this is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `Documentation/admin-
guide/cgroup-v1/memcg_test.rst`, `2 insertions(+), 4 deletions(-)`. No
functions modified. Scope: single-file documentation-only surgical
change.

Step 2.2 Record: before, the section was titled `charge-commit-cancel`,
listed `mem_cgroup_commit_charge()` or `mem_cgroup_cancel_charge()`, and
described `cancel()`. After, it is titled `charge-commit`, lists
`commit_charge()`, and removes the cancellation text.

Step 2.3 Record: bug category is documentation/comment correctness.
Specific mechanism: removes stale references to APIs that are absent in
current `6.19.y`/`7.0.y` code and in `origin/master`.

Step 2.4 Record: fix quality is obviously correct for trees whose memcg
code no longer has `mem_cgroup_commit_charge()` /
`mem_cgroup_cancel_charge()`. Regression risk is zero runtime risk, but
there is a branch-selection concern: `stable/linux-6.12.y` still
contains those functions, so this exact doc update would be misleading
there.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` before the candidate shows the stale doc
lines came from `f3f5edc5e41e` in this repository’s history. `git blame
origin/master` shows the changed lines attributed to `d8769544bde51`.

Step 3.2 Record: no `Fixes:` tag. I still inspected referenced commit
`1d8f136a421f26747e58c01281cba5bffae8d289`; it removed prototypes and
implementations for `mem_cgroup_commit_charge()`,
`mem_cgroup_cancel_charge()`, and related hugetlb try/commit/cancel
helpers.

Step 3.3 Record: recent history for `Documentation/admin-
guide/cgroup-v1/memcg_test.rst` on `origin/master` has only the file
introduction/import commit and this candidate. Related path history
shows the candidate was merged via `cgroup-for-7.1-rc2-fixes`. No
prerequisite doc series found.

Step 3.4 Record: author `T.J. Mercier` has at least one other cgroup-
related commit in `origin/master`; Tejun Heo is listed in `MAINTAINERS`
as cgroup maintainer and committed the patch.

Step 3.5 Record: no code dependencies for the patch itself. It can apply
standalone to the current `stable/linux-7.0.y` checkout. Applicability
must be gated by whether the target tree’s code has removed the old
APIs.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c d8769544bde51...` found the original
submission at
`https://patch.msgid.link/20260430201142.240387-1-tjmercier@google.com`.
`b4 dig -a` found only v1 of a single-patch series. The mbox contains
Tejun’s reply: “Applied to cgroup/for-7.1-fixes.” No NAKs or concerns
found in the saved thread.

Step 4.2 Record: `b4 dig -w` shows recipients included cgroup
maintainers/list and docs list: `tj@kernel.org`, `hannes@cmpxchg.org`,
`mkoutny@suse.com`, `cgroups@vger.kernel.org`, `corbet@lwn.net`,
`skhan@linuxfoundation.org`, `linux-doc@vger.kernel.org`, `linux-
kernel@vger.kernel.org`.

Step 4.3 Record: no `Reported-by` or bug-report `Link:` tags. No syzbot,
bugzilla, or user-impact bug report applies.

Step 4.4 Record: b4 found a standalone single-patch series, not part of
a multi-patch dependency chain.

Step 4.5 Record: web search did not find stable-list discussion for this
exact patch. `WebFetch` to lore/patch.msgid was blocked by Anubis, but
b4 successfully fetched the mbox.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: no functions modified by the diff.

Step 5.2 Record: no callers affected by the diff. For documentation
accuracy, I verified current `stable/linux-7.0.y` code has
`commit_charge()` callers in `charge_memcg()`,
`mem_cgroup_replace_folio()`, and `mem_cgroup_migrate()`.

Step 5.3 Record: no changed callees. The relevant current code has
`commit_charge()` assigning `folio->memcg_data`, and callers also invoke
`memcg1_commit_charge()` where appropriate.

Step 5.4 Record: runtime reachability is not relevant because no
executable code changes.

Step 5.5 Record: similar stale docs pattern exists in stable branches;
however code state differs by branch. `6.19.y`/`7.0.y` have stale docs
and no old API. `6.12.y` still has `mem_cgroup_commit_charge()` and
`mem_cgroup_cancel_charge()` in code.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy stale documentation exists in
`stable/linux-7.0.y`, `stable/linux-6.19.y`, `stable/linux-6.18.y`,
`stable/linux-6.6.y`, `stable/linux-6.1.y`, `stable/linux-5.15.y`, and
`stable/linux-5.10.y` by exact doc grep. I verified the old APIs are
absent in several of those trees, but `stable/linux-6.12.y` still
contains `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`,
so this exact upstream text is not universally correct for all
maintained stable lines.

Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `stable/linux-7.0.y` checkout. Expected backport difficulty:
clean for trees with matching doc context; branch-specific review needed
for `6.12.y`.

Step 6.3 Record: no related stable fix for this exact doc update found
by local stable branch ancestry checks or web search.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is cgroup-v1 memcg documentation.
Criticality: peripheral/runtime-none; important only for documentation
correctness.

Step 7.2 Record: cgroup and memcg areas are active; recent
`origin/master` history includes multiple cgroup/mm fixes. The candidate
was applied by the cgroup maintainer.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is documentation readers and
developers/admins consulting old cgroup-v1 memcg internals. No kernel
runtime users are affected.

Step 8.2 Record: trigger condition is reading or relying on the stale
documentation. Unprivileged users cannot trigger a kernel failure
because there is no runtime behavior.

Step 8.3 Record: failure mode is incorrect documentation. Severity: LOW.
It can mislead developers/admins, but it does not fix crash, corruption,
leak, deadlock, or security behavior.

Step 8.4 Record: benefit is low but real for documentation correctness,
especially because the stable rules exception allows
documentation/comment fixes and runtime risk is zero. Risk is very low
for branches whose code matches the new text; risk is documentation-
regression risk if applied to a branch like `6.12.y` where cancellation
APIs still exist.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: tiny docs-only patch;
corrects verified stale references in current `7.0.y` and `6.19.y`;
applied by cgroup maintainer; no runtime regression risk; documentation
fixes are allowed. Evidence against: no runtime bug or user-visible
stability issue; not correct for every stable branch, specifically
verified `6.12.y` still has the old commit/cancel APIs. Unresolved: I
did not exhaustively validate every maintained stable branch’s memcg API
state.

Step 9.2 Stable rules checklist:
1. Obviously correct and tested? Yes for matching-code branches;
   verified by code grep, `git diff --check`, and `git apply --check` on
   `7.0.y`.
2. Fixes a real bug that affects users? It fixes incorrect
   documentation, not runtime behavior.
3. Important issue? No runtime severity; LOW documentation correctness
   issue.
4. Small and contained? Yes, 6-line docs-only diff in one file.
5. No new features or APIs? Yes.
6. Can apply to stable trees? Yes to at least current `7.0.y`; should
   not be applied blindly to `6.12.y`.

Step 9.3 Record: exception category is documentation fix.

Step 9.4 Decision: backport is acceptable for stable trees whose memcg
implementation no longer has charge cancellation APIs. It should be
excluded from trees like `6.12.y` where the old APIs still exist. With
that branch-selection caveat, this qualifies under the documentation-fix
exception.

Verification:
- [Phase 1] Parsed candidate commit
  `d8769544bde51b0ac980d10f8fe9f9fed6c95995`: only two Signed-off-by
  tags, no bug/report/stable tags.
- [Phase 2] `git show --stat --patch`: confirmed one docs file, `2
  insertions(+), 4 deletions(-)`.
- [Phase 3] `git show 1d8f136a421f...`: confirmed referenced commit
  removed `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`
  from mainline code.
- [Phase 3] `git log origin/master --grep`: found candidate and merge
  via `cgroup-for-7.1-rc2-fixes`.
- [Phase 4] `b4 dig`: found lore thread and exact patch-id match.
- [Phase 4] `b4 dig -a`: only v1 single-patch series.
- [Phase 4] `b4 dig -w`: relevant cgroup and docs maintainers/lists were
  included.
- [Phase 4] Saved mbox: confirmed Tejun replied “Applied to
  cgroup/for-7.1-fixes”; no NAKs or stable nomination found.
- [Phase 5] `rg`/`git grep`: confirmed current code uses
  `commit_charge()` and no longer has old API names in `7.0.y`.
- [Phase 6] `git apply --check`: candidate applies cleanly to current
  `7.0.y`.
- [Phase 6] Branch checks: `6.12.y` still has
  `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, so this
  patch must not be applied there unchanged.
- [Phase 8] Runtime impact verified as none because only
  `Documentation/admin-guide/cgroup-v1/memcg_test.rst` changes.

**YES**

 Documentation/admin-guide/cgroup-v1/memcg_test.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 9f8e27355cba5..7c7cd457cf695 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -47,21 +47,19 @@ Please note that implementation details can be changed.
 	  Called when swp_entry's refcnt goes down to 0. A charge against swap
 	  disappears.
 
-3. charge-commit-cancel
+3. charge-commit
 =======================
 
 	Memcg pages are charged in two steps:
 
 		- mem_cgroup_try_charge()
-		- mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
+		- commit_charge()
 
 	At try_charge(), there are no flags to say "this page is charged".
 	at this point, usage += PAGE_SIZE.
 
 	At commit(), the page is associated with the memcg.
 
-	At cancel(), simply usage -= PAGE_SIZE.
-
 Under below explanation, we assume CONFIG_SWAP=y.
 
 4. Anonymous
-- 
2.53.0

[PATCH AUTOSEL 7.0] docs: hwmon: sy7636a: fix temperature sysfs attribute name

[Sasha Levin]

From: Chen-Shi-Hong <eric039eric@gmail.com>

[ Upstream commit 51f57607e30bee282a1d40845f89a311cbb26481 ]

The hwmon sysfs naming convention uses
temp[1-*]_input for temperature channels.

Documentation/hwmon/sy7636a-hwmon.rst currently documents
temp0_input, while the driver uses the standard hwmon
temperature channel interface.

Update the documentation to use temp1_input.

Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
Link: https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: Subsystem is `docs: hwmon: sy7636a`. Action verb is `fix`.
Claimed intent is to correct the documented temperature sysfs attribute
name from `temp0_input` to `temp1_input`.

Record: Tags present: `Signed-off-by: Chen-Shi-Hong
<eric039eric@gmail.com>`, `Link:
https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@gmail.com`,
`Signed-off-by: Guenter Roeck <linux@roeck-us.net>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Record: The commit describes a documentation bug: the sy7636a hwmon
document names `temp0_input`, while hwmon temperature channels are named
`temp[1-*]_input`. No crash, data corruption, or runtime bug is claimed.

Record: This is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.

## Phase 2: Diff Analysis
Record: One file changed: `Documentation/hwmon/sy7636a-hwmon.rst`, 1
insertion and 1 deletion. No functions modified. Scope is a single-file
documentation-only surgical fix.

Record: Before, the document told users to read `temp0_input`. After, it
tells users to read `temp1_input`. No normal/error/init runtime path
changes.

Record: Bug category is documentation/API-description correctness.
Verified against `Documentation/hwmon/sysfs-interface.rst`, which
documents `temp[1-*]_input`, and `drivers/hwmon/hwmon.c`, where
temperature attributes use `temp%d_input` with base index `1`.

Record: Fix quality is obviously correct and minimal. Runtime regression
risk is zero because no code changes.

## Phase 3: Git History Investigation
Record: `git blame` shows `temp0_input` was introduced by
`de34a40532507` when the sy7636a hwmon driver/doc was added. Ancestry
checks show that commit is not in `v5.17` but is in `v5.18`, so the
documentation bug exists from v5.18 onward where the driver exists.

Record: No `Fixes:` tag is present, so there was no Fixes target to
follow.

Record: Related file history on `origin/master`: `51f57607e30be` doc
attribute fix, `2f88425ef590b` regulator-enable leak fix,
`68c2a8b59d231` sensor description doc fix, `80038a758b7fc` alias
addition, `5b5d8ae019543` constification, `a96f688b4e446` underline
warning fix, `de34a40532507` driver addition. This patch is standalone
for trees with the current doc context.

Record: Author history under hwmon/doc paths shows only this commit from
Chen-Shi-Hong in the checked history. Guenter Roeck, the hwmon
maintainer, committed/applied it.

Record: No functional dependencies. For older stable trees that do not
contain `68c2a8b59d231`, the exact patch context differs and needs a
trivial manual backport.

## Phase 4: Mailing List And External Research
Record: `b4 dig -c 51f57607e30be` found the original submission at
`https://patch.msgid.link/20260514154108.1937-1-eric039eric@gmail.com`.

Record: `b4 dig -a` found only v1 of a single-patch series. No newer
unapplied revision found.

Record: `b4 dig -w` showed recipients included Chen-Shi-Hong, Guenter
Roeck, Jonathan Corbet, Shuah Khan, `linux-hwmon`, `linux-doc`, and
`linux-kernel`.

Record: The b4-fetched thread contains Guenter Roeck replying “Applied.”
No NAKs, objections, or stable-specific nomination were found in that
thread. Lore `WebFetch` was blocked by Anubis, but `b4` successfully
retrieved the thread.

## Phase 5: Code Semantic Analysis
Record: No code functions are modified.

Record: Manual code tracing verified the documentation claim:
`drivers/hwmon/sy7636a-hwmon.c` registers `HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT)`. `drivers/hwmon/hwmon.c` formats temperature attributes
with `temp%d_input`, and `hwmon_attr_base()` returns `1` for temperature
sensors. Therefore the first temperature channel is `temp1_input`.

Record: Callers/callees are not applicable to the patch because it
changes documentation only. The affected “path” is users reading the
hwmon documentation.

Record: Similar pattern check found the generic hwmon documentation and
many hwmon docs use `temp1_input`, supporting the correction.

## Phase 6: Stable Tree Analysis
Record: `v5.15` does not contain `Documentation/hwmon/sy7636a-hwmon.rst`
or `drivers/hwmon/sy7636a-hwmon.c`, so the patch is not applicable
there.

Record: `v6.1`, `v6.6`, and `v6.12` contain the sy7636a driver and the
wrong `temp0_input` documentation. `v7.0` contains the wrong attribute
name with the newer “external NTC” text.

Record: The exact patch applies cleanly to the current
`stable/linux-7.0.y` checkout. It does not apply cleanly to `v6.1` or
`v6.6` because the surrounding description text differs before the later
doc description fix; a trivial one-line context-adjusted backport is
needed there.

Record: No alternate fix for this exact documentation bug was found in
local stable history.

## Phase 7: Subsystem Context
Record: Subsystem is hwmon documentation. Criticality is low for
runtime, but it documents a userspace-visible sysfs ABI path for sy7636a
hardware users.

Record: The sy7636a hwmon files have low churn and only a handful of
targeted fixes since introduction.

## Phase 8: Impact And Risk
Record: Affected population is sy7636a hardware users and anyone writing
scripts or instructions based on
`Documentation/hwmon/sy7636a-hwmon.rst`.

Record: Trigger is reading/following the documentation. If followed
literally, users look for a non-existent `temp0_input` instead of the
actual `temp1_input`.

Record: Failure severity is LOW: documentation/user guidance bug, not a
kernel crash or data corruption issue.

Record: Benefit is modest but real: correct stable documentation for a
userspace-visible hwmon attribute. Risk is effectively zero: one
documentation line, no code, no ABI change.

## Phase 9: Final Synthesis
Evidence for backporting: verified documentation is wrong; verified
driver/core generate `temp1_input`; patch is one-line documentation-
only; hwmon maintainer applied it; documentation fixes are an allowed
stable exception with no runtime regression risk.

Evidence against backporting: it is not a serious runtime bug, security
issue, crash, or data corruption fix. Older stable trees before the
sensor-description doc change need a trivial context adjustment.

Stable rules checklist: obviously correct, yes; fixes a real
documentation bug, yes; important runtime issue, no; small and
contained, yes; no new feature/API, yes; stable applicability, yes for
v7.0 cleanly and older applicable with minor backport adjustment.
Exception category: documentation fix.

Verification:
- [Phase 1] Parsed exact commit `51f57607e30be` from `origin/master` and
  confirmed tags/message.
- [Phase 2] Inspected exact diff: one doc line changes `temp0_input` to
  `temp1_input`.
- [Phase 3] `git blame` confirmed `temp0_input` came from
  `de34a40532507`; ancestry checks place it first in v5.18.
- [Phase 4] `b4 dig` found the original patch; `b4 dig -a` showed v1
  only; `b4 dig -w` showed appropriate hwmon/doc recipients; b4 mbox
  showed Guenter replied “Applied.”
- [Phase 5] Read sy7636a driver and hwmon core; confirmed first
  temperature channel is named `temp1_input`.
- [Phase 6] Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v7.0`
  content; exact patch applies to current 7.0 stable, not directly to
  v6.1/v6.6 due context.
- [Phase 8] Confirmed no runtime code changes, so regression risk is
  zero.

This should be backported where the sy7636a documentation exists, with
trivial context adjustment for older trees as needed.

**YES**

 Documentation/hwmon/sy7636a-hwmon.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst
index 0143ce0e5db76..03d866aba6e81 100644
--- a/Documentation/hwmon/sy7636a-hwmon.rst
+++ b/Documentation/hwmon/sy7636a-hwmon.rst
@@ -22,5 +22,5 @@ The following sensors are supported
 sysfs-Interface
 ---------------
 
-temp0_input
+temp1_input
 	- Temperature of external NTC (milli-degree C)
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] Documentation: kvm: update links in the references section of AMD Memory Encryption

[Sasha Levin]

From: Ninad Naik <ninadnaik07@gmail.com>

[ Upstream commit 80f4a7b8ce7513c203562191426e4d4cc635b095 ]

Replace non-working links in the reference section with the working ones.

Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Link: https://patch.msgid.link/20260511174302.811918-1-ninadnaik07@gmail.com/
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 Record: Subsystem `Documentation: kvm`; action verb `update` /
body verb `Replace`; intent is to replace non-working AMD Memory
Encryption reference links with working links.

Step 1.2 Record: Tags found: `Signed-off-by: Ninad Naik
<ninadnaik07@gmail.com>`, `Link: https://patch.msgid.link/20260511174302
.811918-1-ninadnaik07@gmail.com/`, `Reviewed-by: Liam Merwick
<liam.merwick@oracle.com>`, `Signed-off-by: Paolo Bonzini
<pbonzini@redhat.com>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Acked-by:`, or `Cc: stable@vger.kernel.org`.

Step 1.3 Record: The commit body describes a documentation issue only:
reference links in `Documentation/virt/kvm/x86/amd-memory-
encryption.rst` no longer work as intended. The user-visible symptom is
stale/broken documentation references for AMD SEV/SEV-SNP material. No
runtime failure, crash, data corruption, or kernel version note is
described.

Step 1.4 Record: This is not a hidden runtime bug fix. It is a direct
documentation fix, which is an allowed stable exception category due to
zero runtime risk.

## Phase 2: Diff Analysis

Step 2.1 Record: One file changed: `Documentation/virt/kvm/x86/amd-
memory-encryption.rst`, 4 insertions and 4 deletions. No functions are
modified. Scope classification: single-file surgical documentation
update.

Step 2.2 Record: Before, four reference labels pointed to older AMD
URLs. After, those labels point to current AMD Technical Information
Portal URLs, and the SNP firmware ABI reference points to a current AMD
PDF path. Only the `References` section is affected.

Step 2.3 Record: Bug category is documentation correctness, specifically
stale external references. No synchronization, memory safety, reference
counting, initialization, type, logic, or hardware workaround code is
involved.

Step 2.4 Record: Fix quality is high: the diff only swaps URL strings,
preserves labels, and does not touch kernel code or public APIs.
Regression risk is effectively limited to the possibility of choosing a
less useful URL, not runtime behavior.

## Phase 3: Git History Investigation

Step 3.1 Record: `git blame` on the reference section showed the white-
paper line came from `fbabc2eaef9fd7` in v6.3-rc1, the SNP firmware ABI
line came from `136d8bc931c84f` in v6.11-rc1, and older reference lines
are present in stable branches back to at least `v5.15` by direct branch
grep. Some blame output for pre-rename lines hit a boundary attribution,
so I did not rely on that boundary commit as the true source.

Step 3.2 Record: No `Fixes:` tag is present, so there is no specific
introducing commit to follow.

Step 3.3 Record: Recent file history on `origin/master` includes KVM
SEV/SNP documentation and API additions, including `20c3c4108d58f`,
`dcbcc2323c806`, `ad27ce155566f`, `dee5a47cc7a45`, and `136d8bc931c84f`.
The candidate is standalone because it only changes URL strings and does
not depend on those code/API changes to be meaningful where the same
reference lines exist.

Step 3.4 Record: `git log --author='Ninad Naik'` showed this author has
other documentation link/spelling style commits, including
`a362ae6e7e85b` for `amd-pstate` dead links and `5ed26ffe57ffc` for a
`hwmon` link. I did not verify the author as a KVM maintainer; Paolo
Bonzini committed/applied it and Liam Merwick reviewed it.

Step 3.5 Record: No code symbols or function dependencies exist. The
patch can apply standalone where the same documentation reference block
exists; older stable branches may need context/path adjustments.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c 80f4a7b8ce751` found the original patch
thread at `https://patch.msgid.link/20260511174302.811918-1-
ninadnaik07@gmail.com`. `b4 dig -a` found only v1; `b4 am -c` found no
newer revision.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to KVM and docs
maintainers/lists, including Paolo Bonzini, Jonathan Corbet, Sean
Christopherson, Michael Roth, Liam Merwick, `kvm@vger.kernel.org`, and
`linux-doc@vger.kernel.org`.

Step 4.3 Record: There is no separate bug report or reporter tag. The
thread contains Liam Merwick’s `Reviewed-by` and Paolo Bonzini’s
“Applied, thanks.” I found no NAKs or concerns in the fetched thread.

Step 4.4 Record: The patch is a one-patch series. No related required
patches were identified.

Step 4.5 Record: Web search did not find stable-specific discussion for
this exact subject/hash. Direct WebFetch of lore stable search was
blocked by Anubis, so stable-list search is partially unverified.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: No functions are modified.

Step 5.2 Record: No callers exist because this is documentation.
Documentation references to this file exist from
`Documentation/virt/kvm/api.rst`, `Documentation/admin-guide/kernel-
parameters.txt`, `Documentation/virt/kvm/x86/index.rst`, and related
documentation pages.

Step 5.3 Record: No callees exist. The changed labels are consumed by
Sphinx/ReST documentation rendering.

Step 5.4 Record: No runtime call chain exists. User impact is
documentation usability for KVM SEV/SEV-SNP developers/users.

Step 5.5 Record: Similar pattern exists in prior documentation link
fixes, including `fbabc2eaef9fd7` for an AMD memory encryption white-
paper URL and `bad0524e24201` for an x86 SEV documentation URL.

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

Step 6.1 Record: Stable branches contain affected references.
`stable/linux-5.15.y` and `stable/linux-6.1.y` contain the old KVM AMD
memory encryption doc with three AMD references. `stable/linux-6.6.y`
contains the three current old references. `stable/linux-6.12.y` through
`stable/linux-7.0.y` contain all four references, including the SNP
firmware ABI link.

Step 6.2 Record: Backport difficulty is clean for the current
`linux-7.0.y`-based tree: `git apply --check` succeeded. Older trees
likely need small manual adjustment: `5.15.y` uses the pre-`x86/` path,
`5.15.y`/`6.1.y` have an older white-paper URL, and `6.6.y` lacks the
SNP firmware ABI line.

Step 6.3 Record: `stable/linux-7.0.y` does not contain this candidate
commit by subject. I found prior related doc-link fixes, but not this
exact KVM reference update in stable branches checked.

## Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: Subsystem is KVM x86 documentation for AMD SEV/SEV-SNP.
Criticality is peripheral for runtime kernel stability, but relevant to
KVM confidential-computing documentation users.

Step 7.2 Record: File history shows active KVM SEV/SNP documentation
churn due to recent SEV-SNP commands and API documentation. The touched
change itself is isolated documentation.

## Phase 8: Impact And Risk Assessment

Step 8.1 Record: Affected population is documentation users, especially
KVM/SEV/SEV-SNP developers and operators consulting AMD specs from
stable kernel docs.

Step 8.2 Record: Trigger condition is reading the documentation
references. It is not syscall- or runtime-triggered, and unprivileged
runtime triggering is not applicable.

Step 8.3 Record: Failure mode is stale/non-direct documentation links.
Severity is LOW for runtime stability, but valid under the
documentation-fix exception.

Step 8.4 Record: Benefit is modest but real: stable documentation points
users at current AMD references. Risk is very low: 4 URL replacements in
one `.rst` file, no code, no ABI, no behavior change. Risk-benefit ratio
is favorable because runtime regression risk is effectively zero.

## Phase 9: Final Synthesis

Step 9.1 Record: Evidence for backporting: documentation fix exception
applies; patch is tiny; reviewed; applied by KVM maintainer Paolo
Bonzini; no NAKs found; affected references exist in stable trees;
current `7.0.y` patch application check succeeds. Evidence against: no
runtime bug, no crash/security/data-loss impact, and older stable
branches need minor backport adjustment. Unresolved: lore stable search
was blocked by Anubis, so I could not fully verify stable-list
discussion.

Step 9.2 Record: Stable rules checklist: obviously correct and reviewed:
yes; fixes a real issue: yes, stale documentation references; important
runtime issue: no, but documentation fixes are an allowed exception;
small and contained: yes, 4 lines changed in one file; no new
features/APIs: yes; can apply to stable: yes for current `7.0.y`, likely
clean for `6.12.y+`, minor adjustment for older branches.

Step 9.3 Record: Exception category: documentation fix. This is
explicitly the kind of zero-runtime-risk update that can be accepted
even though it is not a runtime correctness fix.

Step 9.4 Record: Decision is YES. Backporting is appropriate for stable
trees that carry the affected documentation, with minor manual
adjustment where older branch context differs.

## Verification

- [Phase 1] `git show --format=fuller --stat --patch 80f4a7b8ce751`:
  confirmed subject, tags, one-file documentation diff, and no runtime-
  code changes.
- [Phase 2] Diff inspection: confirmed 4 URL replacements only in
  `Documentation/virt/kvm/x86/amd-memory-encryption.rst`.
- [Phase 3] `git blame -L 652,664`: confirmed local history for the
  reference block, including `fbabc2eaef9fd7` and `136d8bc931c84f`.
- [Phase 3] `git describe --contains`: confirmed `fbabc2eaef9fd7` first
  appears by v6.3-rc1 and `136d8bc931c84f` by v6.11-rc1.
- [Phase 3] `git log origin/master --oneline -20 --
  Documentation/virt/kvm/x86/amd-memory-encryption.rst`: confirmed
  recent KVM SEV/SNP doc history and candidate placement.
- [Phase 4] `b4 dig -c 80f4a7b8ce751`: found original patch thread by
  patch-id.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -a`: confirmed only v1 series.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -w`: confirmed KVM/docs maintainers
  and lists were included.
- [Phase 4] `b4 mbox`/saved thread plus `rg`: confirmed `Reviewed-by:
  Liam Merwick` and Paolo’s “Applied, thanks”; found no NAK/stable
  request text.
- [Phase 4] WebFetch of lore/patch URLs was blocked by Anubis; b4
  successfully fetched the thread.
- [Phase 5] `rg` in the doc file: confirmed changed labels are
  referenced by SEV/SNP documentation text.
- [Phase 5] `rg` under `Documentation`: confirmed documentation pages
  link to `amd-memory-encryption.rst`.
- [Phase 6] `git grep` across `stable/linux-5.15.y`, `6.1.y`, `6.6.y`,
  `6.12.y`, `6.15.y`, `6.16.y`, `6.17.y`, `6.18.y`, `6.19.y`, and
  `7.0.y`: confirmed affected old references exist and identified branch
  differences.
- [Phase 6] `git diff 80f4a7b8ce751^ 80f4a7b8ce751 | git apply --check`:
  confirmed clean application to the current `7.0.y`-based working tree.
- [Phase 8] URL checks with Python HEAD/WebFetch: confirmed old direct
  AMD URLs no longer behave as direct PDF references in several cases,
  while the new SNP ABI URL returns an AMD PDF; other new AMD TIP URLs
  resolve to AMD documentation portal pages.
- UNVERIFIED: full stable mailing-list history, because direct lore
  stable WebFetch was blocked by Anubis and web search found no exact
  stable discussion.

**YES**

 Documentation/virt/kvm/x86/amd-memory-encryption.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index b2395dd4769de..bd04a908a8dbd 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -656,8 +656,8 @@ References
 See [white-paper]_, [api-spec]_, [amd-apm]_, [kvm-forum]_, and [snp-fw-abi]_
 for more info.
 
-.. [white-paper] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
-.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
-.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34)
+.. [white-paper] https://docs.amd.com/v/u/en-US/memory-encryption-white-paper
+.. [api-spec] https://docs.amd.com/v/u/en-US/55766_PUB_3.24_SEV_API
+.. [amd-apm] https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 (section 15.34)
 .. [kvm-forum]  https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
-.. [snp-fw-abi] https://www.amd.com/system/files/TechDocs/56860.pdf
+.. [snp-fw-abi] https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: doc: cs35l56: Update path to HDA driver source

[Sasha Levin]

From: Richard Fitzgerald <rf@opensource.cirrus.com>

[ Upstream commit 74e8409821ac8cda70bf23eb593f2c7f6e3b5a2f ]

The HDA drivers were moved to sound/hda/... so update a Documentation
reference that still pointed to the old location.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260511104148.36382-1-rf@opensource.cirrus.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
Record 1.1: Subsystem `ALSA: doc: cs35l56`; action verb `Update`;
intent: correct a stale documentation path to the HDA driver source.

Record 1.2: Tags present in supplied message: `Signed-off-by: Richard
Fitzgerald <rf@opensource.cirrus.com>`, `Link: https://patch.msgid.link/
20260511104148.36382-1-rf@opensource.cirrus.com`, `Signed-off-by:
Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-by:`, `Tested-
by:`, `Reviewed-by:`, `Acked-by:`, or `Cc: stable`.

Record 1.3: The body says the HDA drivers moved to `sound/hda/...`,
leaving this documentation reference pointing at the old
`sound/pci/hda/...` location. Symptom is incorrect documentation only;
no runtime failure, crash, data corruption, or security impact is
described.

Record 1.4: This is not a hidden runtime bug fix. It is a direct
documentation correction.

## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/sound/codecs/cs35l56.rst`,
1 insertion and 1 deletion. No functions modified. Scope: single-file
documentation-only surgical change.

Record 2.2: Before: HDA users were pointed to
`sound/pci/hda/cs35l56_hda.c`. After: they are pointed to
`sound/hda/codecs/side-codecs/cs35l56_hda.c`.

Record 2.3: Bug category: documentation correctness fix. Verified
current tree has `sound/hda/codecs/side-codecs/cs35l56_hda.c`;
`sound/pci/hda` does not exist in this checkout.

Record 2.4: Fix quality is obvious and minimal. Regression risk is
runtime zero, but backport targeting matters: applying it to older trees
where the driver is still under `sound/pci/hda` would make the
documentation wrong.

## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the stale documentation line was
introduced by `088fb4ee17fc4` (`ALSA: doc: cs35l56: Add information
about Cirrus Logic CS35L54/56/57`). The line became stale when
`6014e9021b28e` moved HDA codec drivers into `sound/hda/codecs`.

Record 3.2: No `Fixes:` tag is present, so there was no Fixes target to
follow.

Record 3.3: Recent file history shows only CS35L56 documentation
updates. Related source movement is `6014e9021b28e`, which renamed
`sound/pci/hda/cs35l56_hda.c` to `sound/hda/codecs/side-
codecs/cs35l56_hda.c`.

Record 3.4: Author Richard Fitzgerald has multiple recent CS35L56/HDA-
related commits in this subsystem, including documentation and HDA
driver fixes.

Record 3.5: Dependency identified: this patch is correct only in trees
that already contain the HDA move commit `6014e9021b28e`.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 am` using message ID
`20260511104148.36382-1-rf@opensource.cirrus.com` found a single patch
submission and reported no newer revision. Direct `WebFetch` to
lore/patch.msgid.link was blocked by Anubis, but `b4` retrieved the
mbox.

Record 4.2: `b4 dig -c` could not be run for the candidate commit
because no candidate commit hash was supplied and the commit was not
found on checked named branches searched. `b4 am` verified author DKIM
signatures and the patch metadata. `b4 dig -c 6014e9021b28e -w` verified
the prerequisite move patch was an ALSA HDA series sent to `linux-sound`
and relevant HDA/Cirrus recipients.

Record 4.3: No bug report, syzbot report, crash report, or user report
is linked.

Record 4.4: Candidate is standalone as a documentation update, but
semantically depends on the prior source-tree move.

Record 4.5: Web searches and local pending branch searches found no
stable-specific discussion for this exact documentation patch.

## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation text only.

Record 5.2: No callers; this is not runtime code.

Record 5.3: No callees; no allocations, locks, I/O, or side effects.

Record 5.4: No userspace-triggerable kernel execution path. Impact is
limited to readers of the documentation.

Record 5.5: Search found the old path only in
`Documentation/sound/codecs/cs35l56.rst` among `.rst` files checked.

## Phase 6: Stable Tree Analysis
Record 6.1: Tag containment shows the documentation exists from
`v6.13+`; the HDA move exists from `v6.17+`. Therefore the stale-path
documentation issue exists only in trees containing both, i.e.
approximately `v6.17+` and later.

Record 6.2: `git apply --check` confirms the patch applies cleanly to
the current `7.0.y` tree. Backport difficulty is trivial for affected
trees, but it must not be applied to trees where the HDA driver still
lives under `sound/pci/hda`.

Record 6.3: No related stable fix for this exact path correction was
found in local pending branches.

## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is ALSA sound documentation for Cirrus CS35L56
HDA/SoundWire amplifiers. Criticality: peripheral/documentation, not
runtime core.

Record 7.2: Sound documentation and HDA side-codec areas are actively
maintained; recent logs show multiple CS35L56/HDA commits.

## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population: developers, maintainers, integrators,
and users consulting this CS35L56 documentation in kernels where the HDA
source has moved.

Record 8.2: Trigger condition: reading the documentation. Not
triggerable as a kernel runtime fault.

Record 8.3: Failure mode: stale documentation path. Severity LOW, but
documentation fixes are explicitly acceptable stable material due zero
runtime risk.

Record 8.4: Benefit is modest but real for affected trees; risk is very
low if limited to trees with `6014e9021b28e`, but negative for older
trees where the old path is still correct.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes an objectively wrong
documentation reference, one-line contained patch, no runtime regression
risk, applies cleanly to current `7.0.y`, documentation/comment fixes
are an accepted stable exception. Evidence against: no runtime bug, no
important crash/security/corruption impact, and it must be branch-
limited. Unresolved: exact upstream candidate commit hash was not
available locally.

Record 9.2: Stable rules: obviously correct: yes; tested: `b4` says
applies cleanly and local `git apply --check` passed; fixes a real bug:
yes, documentation bug; important runtime issue: no; small and
contained: yes, 1 line; no new feature/API: yes; applies to affected
stable trees: yes, for trees after the HDA move.

Record 9.3: Exception category: documentation fix.

Record 9.4: Decision: backport is appropriate, but only to stable trees
that already contain the HDA source move to `sound/hda/codecs/side-
codecs`. Do not apply to older stable trees where
`sound/pci/hda/cs35l56_hda.c` remains the correct path.

## Verification
- [Phase 1] Parsed supplied commit message and downloaded mbox:
  confirmed subject, author, message ID, and one-line documentation
  rationale.
- [Phase 2] Read `Documentation/sound/codecs/cs35l56.rst`: confirmed old
  path is present.
- [Phase 2] Checked filesystem: confirmed `sound/hda/codecs/side-
  codecs/cs35l56_hda.c` exists and `sound/pci/hda` does not in current
  tree.
- [Phase 3] `git blame -L 35,45`: confirmed stale line came from
  `088fb4ee17fc4`.
- [Phase 3] `git show 6014e9021b28e`: confirmed HDA codecs, including
  `cs35l56_hda.c`, were moved from `sound/pci/hda` to
  `sound/hda/codecs/side-codecs`.
- [Phase 4] `b4 am`: retrieved the patch, found one patch, no newer
  revision, DKIM signed.
- [Phase 4] `b4 dig -c <msgid>`: failed because `b4 dig` requires a
  commit-ish, not a message ID.
- [Phase 4] WebFetch to lore/patch.msgid.link: blocked by Anubis.
- [Phase 6] `git tag --contains`: documentation starts at `v6.13+`; HDA
  move starts at `v6.17+`.
- [Phase 6] `git apply --check`: candidate patch applies cleanly to
  current tree.
- [Phase 6] `git ls-tree`: `v6.6`/`v6.12` have old HDA source path and
  no affected doc; `v6.18` has both affected doc and new HDA source
  path.
- UNVERIFIED: Candidate final upstream commit hash, because it was not
  found on searched local named branches and was not provided.

**YES**

 Documentation/sound/codecs/cs35l56.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/sound/codecs/cs35l56.rst b/Documentation/sound/codecs/cs35l56.rst
index d5363b08f5152..b3f8c1c238518 100644
--- a/Documentation/sound/codecs/cs35l56.rst
+++ b/Documentation/sound/codecs/cs35l56.rst
@@ -40,7 +40,7 @@ There are two drivers in the kernel
 
 *For systems using SoundWire*: sound/soc/codecs/cs35l56.c and associated files
 
-*For systems using HDA*: sound/pci/hda/cs35l56_hda.c
+*For systems using HDA*: sound/hda/codecs/side-codecs/cs35l56_hda.c
 
 Firmware
 ========
-- 
2.53.0

[PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team

[Sasha Levin]

From: Willy Tarreau <w@1wt.eu>

[ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]

With the increase of automated reports, the security team is dealing
with way more messages than really needed. The reporting process works
well with most teams so there is no need to systematically involve the
security team in reports.

Let's suggest to keep it for small lists of recipients and new reporters
only. This should continue to cover the risk of lost messages while
reducing the volume from prolific reporters.

Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260509094755.2838-2-w@1wt.eu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `Documentation/process/security-bugs`; action verb
`do not`; intent is to update security bug reporting instructions so
reporters do not always Cc the security team.

Record 1.2: Tags present: `Cc: Greg KH <gregkh@linuxfoundation.org>`,
`Cc: Leon Romanovsky <leon@kernel.org>`, `Reviewed-by: Leon Romanovsky
<leon@kernel.org>`, `Reviewed-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>`, `Signed-off-by: Willy Tarreau
<w@1wt.eu>`, `Signed-off-by: Jonathan Corbet <corbet@lwn.net>`,
`Message-ID: <20260509094755.2838-2-w@1wt.eu>`. No `Fixes:`, no
`Reported-by:`, no `Tested-by:`, no `Cc: stable`.

Record 1.3: The body describes a process/documentation problem:
increased automated reports create more mail to the security team than
needed. Symptom is excess security-team involvement, not a kernel
runtime crash or data corruption. No affected kernel versions are named.

Record 1.4: This is not a hidden code bug fix. It is an explicit
documentation/process update that corrects now-overbroad guidance.

## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/process/security-bugs.rst`,
9 insertions and 1 deletion in the submitted patch. No functions are
modified. Scope is single-file documentation-only.

Record 2.2: Before: reports “must” be sent to maintainers with the
security team in Cc. After: reports still go to maintainers, but
security-team Cc is mandatory only for two-or-fewer recipients, advised
for early reports or specific help, and no longer necessary for
comfortable reporters sending to large teams.

Record 2.3: Bug category is documentation/process correctness. No
resource leak, race, memory safety, refcount, initialization, endian, or
hardware quirk mechanism exists.

Record 2.4: Fix quality is high for its scope: small, reviewed,
documentation-only, no runtime behavior. Regression risk is limited to
possibly changing reporter behavior; no kernel runtime regression is
possible from the diff itself.

## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the replaced sentence was introduced by
`a72b832a482372` (“Documentation: explain how to find maintainers
addresses for security reports”), first contained by `v7.0-rc7~8^2~2`.

Record 3.2: No `Fixes:` tag is present, so there is no Fixes target to
follow.

Record 3.3: Recent history of `Documentation/process/security-bugs.rst`
shows a series of security-reporting documentation updates by Willy
Tarreau, including contact/process clarifications and typo fixes. This
patch is standalone at the diff level but part of a three-patch
documentation series.

Record 3.4: The author has multiple recent commits in
`Documentation/process/security-bugs.rst`. Maintainer lookup identifies
`Security Officers <security@kernel.org>` and `Jonathan Corbet
<corbet@lwn.net>` for this file.

Record 3.5: No code dependencies or functions exist. The exact patch
depends on the newer rewritten security-bugs document layout present in
`7.0.y`; older stable branches do not contain `a72b832a482372`.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c` could not be used because no candidate commit
SHA was available locally or in the prompt, and local `master`, `docs-
next`, and `all-next` searches did not find the commit object. Using the
supplied Message-ID, `b4 am` found the original submission at
`https://patch.msgid.link/20260509094755.2838-1-w@1wt.eu`.

Record 4.2: `b4 am` and the mbox show v3 of a 3-patch series, 33 thread
messages, sent to Greg KH, Leon Romanovsky, Jonathan Corbet, Shuah Khan,
`security@kernel.org`, `workflows@vger.kernel.org`, `linux-
doc@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Record 4.3: No bug report link, syzbot report, Bugzilla report, or user
crash report exists. Lore WebFetch was blocked by Anubis, but `b4`
successfully fetched the mbox.

Record 4.4: Series context: patch 1/3 is this Cc guidance change; patch
2/3 adds security-bug/threat-model documentation; patch 3/3 clarifies
AI-assisted reports. Cover letter says v2 reworded the “when to Cc” part
based on Greg’s feedback; v3 included wording/structure feedback and
added reviews.

Record 4.5: I found no stable-specific discussion or stable nomination
in the fetched thread. Jonathan Corbet said he applied the series to
`docs-fixes` after short linux-next exposure.

## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation only.

Record 5.2: No callers; affected audience is readers of
`Documentation/process/security-bugs.rst`.

Record 5.3: No callees or side effects.

Record 5.4: Reachability is not runtime reachability. The path is
“reporter reads stable-tree documentation and follows reporting
instructions.”

Record 5.5: `rg` found the old mandatory-Cc sentence only in
`Documentation/process/security-bugs.rst`; related security-team
references remain elsewhere in the same document.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record 6.1: `a72b832a482372` is an ancestor of `stable/linux-7.0.y` but
not of local `stable/linux-5.15.y`, `stable/linux-6.1.y`,
`stable/linux-6.6.y`, `stable/linux-6.12.y`, `stable/linux-6.18.y`, or
`stable/linux-6.19.y`. So this exact buggy/obsolete sentence is
confirmed in `7.0.y`; older local stable trees have older document
layouts.

Record 6.2: `b4` reports the series base applies cleanly to the current
tree, which is `stable/linux-7.0.y`. Older stable trees would need a
different documentation backport if maintainers wanted equivalent
guidance there.

Record 6.3: No related stable fix for this exact wording was found in
local history.

## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is documentation/process, specifically security
bug reporting. Criticality is process-important, not runtime
core/driver/filesystem criticality.

Record 7.2: The file has active recent development, with several
2025-2026 security-reporting documentation updates.

## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population is documentation readers: security bug
reporters, maintainers, and the kernel security team. No running kernel
users are directly affected.

Record 8.2: Trigger is following the stable tree’s security-bug
reporting documentation. This can be done by any reporter, but it is not
a syscall or kernel execution path.

Record 8.3: Failure mode severity is low for runtime stability, but
medium for security-process efficiency: the old wording can
unnecessarily add the private security team to large-team reports.

Record 8.4: Benefit is moderate for keeping security reporting guidance
current and reducing unnecessary private-list traffic. Risk is very low
because the patch is documentation-only and reviewed.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: documentation-only; zero runtime
regression risk; corrects overbroad/obsolete reporting guidance;
reviewed by Leon Romanovsky and Greg Kroah-Hartman; applied by
documentation maintainer Jonathan Corbet; relevant to security reporting
workflow; clean for `7.0.y`.

Evidence against: it does not fix a kernel runtime bug, crash, security
vulnerability, corruption, or deadlock; older stable trees do not
contain the exact rewritten section, so this exact patch is mainly
applicable to `7.0.y`.

Unresolved: I could not run `b4 dig -c` without a commit SHA, and
WebFetch of lore was blocked by Anubis. The `b4` Message-ID fetch
supplied the needed thread content.

Record 9.2: Stable rules: obviously correct and reviewed: yes. Fixes
real user-visible runtime bug: no. Important
crash/security/corruption/deadlock: no. Small and contained: yes, one
documentation file. No new feature/API: yes. Applies to stable: yes for
`7.0.y`; older branches need separate handling.

Record 9.3: Exception category: documentation fix/update. This is the
reason it qualifies despite not being a runtime bug.

Record 9.4: Decision: backport where the affected documentation exists,
especially `7.0.y`. The runtime benefit is nonexistent, but the risk is
also nonexistent, and stable policy exceptions allow documentation fixes
that correct obsolete guidance.

## Verification
- Phase 1: Parsed supplied commit tags and b4 patch headers; confirmed
  no `Fixes:`, `Reported-by:`, `Tested-by`, or `Cc: stable`.
- Phase 2: Read supplied diff and b4 patch; confirmed one documentation
  file, 9 insertions/1 deletion, no code.
- Phase 3: Ran `git blame -L 148,152 -- Documentation/process/security-
  bugs.rst`; old sentence introduced by `a72b832a482372`.
- Phase 3: Ran `git describe --contains a72b832a482372`; first contained
  around `v7.0-rc7~8^2~2`.
- Phase 3: Ran file and author history commands; confirmed recent
  related docs updates by Willy Tarreau.
- Phase 4: Local `git log` searches on current history, `master`, `docs-
  next`, and `all-next` did not find the candidate commit object.
- Phase 4: `b4 am -o /tmp/security-bugs-b4
  20260509094755.2838-2-w@1wt.eu` found a v3 3-patch series, 33
  messages, and reported clean apply to current tree.
- Phase 4: `b4 mbox` saved the thread mbox; `rg` found no stable
  nomination or NAK for this patch.
- Phase 4: WebFetch of lore URLs was blocked by Anubis; not used for the
  final decision.
- Phase 5: `rg` over `Documentation` confirmed the exact mandatory-Cc
  sentence appears in `Documentation/process/security-bugs.rst`.
- Phase 6: `git merge-base --is-ancestor a72b832a482372
  stable/linux-7.0.y` returned true; checks for `5.15.y`, `6.1.y`,
  `6.6.y`, `6.12.y`, `6.18.y`, and `6.19.y` returned false.
- Phase 7: `./scripts/get_maintainer.pl` identified Security Officers
  and Jonathan Corbet for the file; `MAINTAINERS` confirms
  `DOCUMENTATION PROCESS`, `SECURITY CONTACT`, and `STABLE BRANCH`
  entries.
- Phase 8: Failure mode verified from commit text and diff only:
  documentation/process burden, not runtime failure.

**YES**

 Documentation/process/security-bugs.rst | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 27b028e858610..6dc525858125e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -148,7 +148,15 @@ run additional tests.  Reports where the reporter does not respond promptly
 or cannot effectively discuss their findings may be abandoned if the
 communication does not quickly improve.
 
-The report must be sent to maintainers, with the security team in ``Cc:``.
+The report must be sent to maintainers.  If there are two or fewer
+recipients in your message, you must also always Cc: the Linux kernel
+security team who will ensure the message is delivered to the proper
+people, and will be able to assist small maintainer teams with processes
+they may not be familiar with.  For larger teams, Cc: the Linux kernel
+security team for your first few reports or when seeking specific help,
+such as when resending a message which got no response within a week.
+Once you have become comfortable with the process for a few reports, it is
+no longer necessary to Cc: the security list when sending to large teams.
 The Linux kernel security team can be contacted by email at
 <security@kernel.org>.  This is a private list of security officers
 who will help verify the bug report and assist developers working on a fix.
-- 
2.53.0

Re: [PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team

[Jonathan Corbet]

Sasha Levin <sashal@kernel.org> writes:

> From: Willy Tarreau <w@1wt.eu>
>
> [ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]
>
> With the increase of automated reports, the security team is dealing
> with way more messages than really needed. The reporting process works
> well with most teams so there is no need to systematically involve the
> security team in reports.

You'll want, at a minimum, f2e65e4e5b4b4b9ecf43f03c3fdbe8c9a8a43a9e to
go with this, or you'll add a broken reference with this commit.

Thanks,

jon