[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-5.10] selftests/cgroup: Fix cg_read_strcmp() empty string comparison

[Sasha Levin]

From: Hongfu Li <lihongfu@kylinos.cn>

[ Upstream commit e32e6f02168f2ad7991eb5d160d312d2001520c8 ]

cg_read_strcmp() allocated a buffer sized to strlen(expected) + 1,
then passed it to read_text() which calls read(fd, buf, size-1).

When comparing against an empty string (""), strlen("") = 0 gives a
1-byte buffer, and read() is asked to read 0 bytes.  The file content
is never actually read, so strcmp("", buf) always returns 0 regardless
of the real content.  This caused cg_test_proc_killed() to always
report the cgroup as empty immediately, making OOM tests pass without
verifying that processes were killed.

Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
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 `selftests/cgroup`; action verb `Fix`; intent
is to correct empty-string comparison in `cg_read_strcmp()`.

Step 1.2 Record: Tags present are:
- `Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>`
- `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 are present.

Step 1.3 Record: The commit describes a concrete selftest bug: for
expected `""`, `strlen(expected) + 1` allocates one byte, and
`read_text()` calls `read(fd, buf, size - 1)`, so zero bytes are read.
The symptom is false success: `cg_test_proc_killed()` can report a
cgroup as empty immediately, so OOM tests can pass without verifying
process death.

Step 1.4 Record: This is a direct bug fix, not hidden cleanup. It fixes
incorrect test validation logic.

## Phase 2: Diff Analysis

Step 2.1 Record: One file changed:
`tools/testing/selftests/cgroup/lib/cgroup_util.c`, with 3 insertions
and 2 deletions. Modified function: `cg_read_strcmp()`. Scope: single-
file surgical selftest helper fix.

Step 2.2 Record: Before, non-NULL `expected` always used
`strlen(expected) + 1`; for `""`, that meant `size == 1` and `cg_read()`
read zero bytes. After, empty expected strings use `size == 2`, allowing
one byte to be read so non-empty file contents are detected.

Step 2.3 Record: Bug category is logic/correctness in a userspace
selftest helper. No kernel runtime locking, refcounting, memory safety,
or API behavior changes.

Step 2.4 Record: The fix is obviously correct for the described case:
empty file still compares equal, non-empty file no longer compares equal
after reading at least one byte. Regression risk is very low and limited
to cgroup selftests.

## Phase 3: Git History Investigation

Step 3.1 Record: Blame shows `cg_read_strcmp()` came from `84092dbcf901`
in v4.18-rc1, and the `size = strlen(expected) + 1` logic was last
touched by `48c2bb0b9cf86` in v4.19-rc5. The bug has therefore existed
across many stable releases.

Step 3.2 Record: No `Fixes:` tag is present. I inspected related commits
anyway: `84092dbcf901` introduced the selftest utility, `48c2bb0b9cf86`
tried to fix `cg_read_strcmp()` but still checked `!expected` rather
than empty `expected`, and `d830020656c5b` changed the NULL case to
return `-1`.

Step 3.3 Record: Recent related history includes `6680c162b4850` adding
`cg_read_strcmp_wait()` and `2c754a84ff16a` moving the utility into
`lib/`. No functional prerequisite for this fix was identified.

Step 3.4 Record: No prior Hongfu Li commits under
`tools/testing/selftests/cgroup` were found. The commit was applied by
Tejun Heo, who is listed as a cgroup maintainer in `MAINTAINERS`.

Step 3.5 Record: No dependent code changes are required for the logic
itself. Older stable trees before the selftest library move need a path-
only backport adjustment.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c e32e6f02168f2...` found the original
submission at
`https://patch.msgid.link/20260509080328.632007-1-lihongfu@kylinos.cn`.
`b4 dig -a` found only v1. The saved mbox shows Tejun replied: “Applied
to cgroup/for-7.1-fixes.” No NAKs or concerns were present in the
fetched thread.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to Tejun Heo,
Johannes Weiner, Michal Koutný, Shuah Khan, cgroups, linux-kselftest,
and linux-kernel, so the right maintainers/lists were included.

Step 4.3 Record: No separate bug report, syzbot report, or bugzilla link
was present.

Step 4.4 Record: No multi-patch series or related required patches were
found; this is standalone.

Step 4.5 Record: Lore WebFetch was blocked by Anubis for stable search.
WebSearch did not find stable-specific discussion for this exact 2026
commit.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: Modified function: `cg_read_strcmp()`.

Step 5.2 Record: Callers found include `cg_read_strcmp_wait()`,
`test_memcontrol.c`, `test_core.c`, `test_kill.c`, `test_pids.c`, and
`test_zswap.c`. Empty-string `cgroup.procs` checks are in
`test_memcontrol.c`.

Step 5.3 Record: The relevant callees are `malloc()`, `cg_read()`,
`read_text()`, `read()`, `strcmp()`, and `free()`.

Step 5.4 Record: Verified call chain: `test_memcontrol` main test loop
-> OOM tests such as `test_memcg_oom_events()` / `cg_test_proc_killed()`
-> `cg_read_strcmp()` -> `cg_read()` -> `read_text()`. This is reachable
by running cgroup kselftests, not by normal kernel runtime use.

Step 5.5 Record: Similar affected pattern exists in stable branches
where `cg_read_strcmp(..., "cgroup.procs", "")` is used and the helper
still has `size = strlen(expected) + 1`.

## Phase 6: Stable Tree Analysis

Step 6.1 Record: I verified the buggy helper and affected empty
`cgroup.procs` checks exist in `stable/linux-5.4.y`, `5.10.y`, `5.15.y`,
`6.1.y`, `6.6.y`, `6.12.y`, `6.17.y`, `6.18.y`, `6.19.y`, and `7.0.y`.

Step 6.2 Record: The patch applies cleanly to current
`stable/linux-7.0.y` with `git apply --check`. Branches using
`tools/testing/selftests/cgroup/cgroup_util.c` instead of
`lib/cgroup_util.c` need a trivial path adjustment.

Step 6.3 Record: Related older fixes are present, but no checked stable
branch contained the candidate’s `expected[0] == '\0'` fix.

## Phase 7: Subsystem Context

Step 7.1 Record: Subsystem is cgroup selftests. Runtime criticality is
peripheral, but test criticality is meaningful for memcg/cgroup
validation.

Step 7.2 Record: The subsystem is active; recent stable history includes
multiple cgroup selftest fixes, and `MAINTAINERS` lists
`tools/testing/selftests/cgroup/` under maintained cgroup ownership.

## Phase 8: Impact And Risk

Step 8.1 Record: Affected users are kernel developers, distributions, CI
systems, and stable maintainers running cgroup kselftests.

Step 8.2 Record: Trigger is running affected cgroup OOM selftests that
compare `cgroup.procs` with `""`. This is not an unprivileged runtime
kernel trigger.

Step 8.3 Record: Failure mode is false PASS / missed test validation,
not a kernel crash or data corruption. Severity: MEDIUM for stable
validation quality.

Step 8.4 Record: Benefit is medium because it prevents false success in
OOM-related stable testing. Risk is very low because the change is tiny,
userspace-only, and does not affect kernel runtime behavior.

## Phase 9: Final Synthesis

Evidence for backporting: fixes a real, verified selftest correctness
bug; bug exists in many stable trees; affects OOM/memcg validation;
patch is tiny and obvious; reviewed/applied by the cgroup maintainer; no
runtime regression risk.

Evidence against backporting: it does not fix a production kernel
crash/security/data-corruption bug directly, only test correctness.

Stable rules checklist:
1. Obviously correct and tested by review? Yes, obviously correct by
   code inspection; no explicit `Tested-by`.
2. Fixes a real bug? Yes, false empty-string comparison in selftests.
3. Important issue? Medium: prevents false PASS in OOM selftests, not
   runtime-critical.
4. Small and contained? Yes, 5-line single-function change.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for 7.0 cleanly; older branches need trivial
   path adjustment.

Exception category: Not a device ID, quirk, DT, build, or documentation
fix. It is a selftest correctness fix.

## Verification

- Phase 1: `git show e32e6f02168f2...` verified subject, body, tags,
  author, committer, and no `Fixes:`/stable tags.
- Phase 2: `git show --patch` verified the 3 insertion / 2 deletion
  change in `cg_read_strcmp()`.
- Phase 3: `git blame -L 99,123 e32e6f^ --
  tools/testing/selftests/cgroup/lib/cgroup_util.c` verified line
  history.
- Phase 3: `git show 84092dbcf901`, `git show 48c2bb0b9cf86`, and `git
  show d830020656c5b` verified related history.
- Phase 4: `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and saved mbox
  verified lore URL, v1-only series, recipients, and Tejun’s applied
  reply.
- Phase 5: `rg "cg_read_strcmp\\(" tools/testing/selftests/cgroup` and
  file reads verified callers and empty-string uses.
- Phase 6: Python checks against stable branches verified buggy code and
  affected tests in listed stable trees.
- Phase 6: `git diff e32e6f^ e32e6f | git apply --check` verified clean
  application to `stable/linux-7.0.y`.
- Phase 7: `rg` in `MAINTAINERS` verified cgroup maintainers and
  selftest path ownership.
- Phase 8: Impact classification is based on verified file path under
  `tools/testing/selftests`, verified test call chain, and no kernel
  runtime files changed.
- UNVERIFIED: I did not run the cgroup selftests, and Lore WebFetch was
  blocked by Anubis for direct stable archive browsing.

**YES**

 tools/testing/selftests/cgroup/lib/cgroup_util.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/cgroup/lib/cgroup_util.c b/tools/testing/selftests/cgroup/lib/cgroup_util.c
index 6a7295347e90b..42f54936f4bbd 100644
--- a/tools/testing/selftests/cgroup/lib/cgroup_util.c
+++ b/tools/testing/selftests/cgroup/lib/cgroup_util.c
@@ -106,8 +106,9 @@ int cg_read_strcmp(const char *cgroup, const char *control,
 	/* Handle the case of comparing against empty string */
 	if (!expected)
 		return -1;
-	else
-		size = strlen(expected) + 1;
+
+	/* needs size > 1, otherwise cg_read() reads 0 bytes */
+	size = (expected[0] == '\0') ? 2 : strlen(expected) + 1;
 
 	buf = malloc(size);
 	if (!buf)
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] cgroup/cpuset: move PF_EXITING check before __GFP_HARDWALL in cpuset_current_node_allowed()

[Sasha Levin]

From: Chen Wandun <chenwandun@lixiang.com>

[ Upstream commit dde2f938d02f2c740d49bb5113dea941f941026a ]

Since prepare_alloc_pages() unconditionally adds __GFP_HARDWALL for the
fast path when cpusets are enabled, the __GFP_HARDWALL check in
cpuset_current_node_allowed() causes the PF_EXITING escape path to be
skipped on the first allocation attempt.  This makes it unreachable in
the common case, so dying tasks can get stuck in direct reclaim or even
trigger OOM while trying to exit, despite being allowed to allocate from
any node.

Move the PF_EXITING check before __GFP_HARDWALL so that dying tasks
can allocate memory from any node to exit quickly, even when cpusets
are enabled.

Also update the function comment to reflect the actual behavior of
prepare_alloc_pages() and the corrected check ordering.

Signed-off-by: Chen Wandun <chenwandun@lixiang.com>
Acked-by: Michal Koutný <mkoutny@suse.com>
Acked-by: Waiman Long <longman@redhat.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 is `cgroup/cpuset`; action verb is “move”;
claimed intent is to move the `PF_EXITING` allowance before the
`__GFP_HARDWALL` rejection in `cpuset_current_node_allowed()` so exiting
tasks can allocate outside their cpuset and finish exiting.

Step 1.2 Record: Tags present in `dde2f938d02f2`:
- `Signed-off-by: Chen Wandun <chenwandun@lixiang.com>`
- `Acked-by: Michal Koutný <mkoutny@suse.com>`
- `Acked-by: Waiman Long <longman@redhat.com>`
- `Signed-off-by: Tejun Heo <tj@kernel.org>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Link:`, or
`Cc: stable@vger.kernel.org` tags in the committed message.

Step 1.3 Record: The body describes a real liveness/allocation bug:
`prepare_alloc_pages()` sets `__GFP_HARDWALL` when cpusets are enabled,
so the existing hardwall rejection returns `false` before the later
`PF_EXITING` escape is reached. The described failure mode is dying
tasks getting stuck in direct reclaim or triggering OOM while trying to
exit.

Step 1.4 Record: This is a hidden bug fix despite the subject saying
“move”: it restores an existing intended exception for `PF_EXITING`
tasks that was unreachable for hardwall allocations.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed, `kernel/cgroup/cpuset.c`, 8
insertions and 6 deletions. The only functional change is inside
`cpuset_current_node_allowed()`. Scope is single-file, surgical.

Step 2.2 Record: Before, for a node outside `current->mems_allowed`, the
code checked `tsk_is_oom_victim()`, then rejected `__GFP_HARDWALL`, then
checked `PF_EXITING`. After, `PF_EXITING` is checked before
`__GFP_HARDWALL`. Comment updates match the behavior change.

Step 2.3 Record: Bug category is logic/liveness correctness in memory
allocation policy. The broken mechanism was an intended “dying task may
allocate anywhere” path being shadowed by an earlier hardwall return.

Step 2.4 Record: The fix is obviously correct by inspection: it only
reorders two independent boolean exits, introduces no locking, no data
structure changes, and no API changes. Regression risk is very low; the
only behavioral relaxation is for tasks already marked `PF_EXITING`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the hardwall rejection is old cpuset
logic from `9bf2229f881767` in 2005; the `PF_EXITING` allowance was
added by `5563e77078d8` in 2005; the OOM-victim allowance was added by
`c596d9f320aa` in 2007. `prepare_alloc_pages()` currently sets
`*alloc_gfp |= __GFP_HARDWALL`; that structure was introduced by
`9cd7555875bb` in 2017, and checked tags show equivalent hardwall first-
attempt behavior exists at least back to `v4.4`.

Step 3.2 Record: No `Fixes:` tag, so there was no specific target commit
to follow.

Step 3.3 Record: Recent `kernel/cgroup/cpuset.c` history shows normal
cpuset churn and a 2025 rename from `cpuset_node_allowed()` to
`cpuset_current_node_allowed()` in `8adce0857769`. That rename is a
backport context issue for older trees, not a semantic dependency.

Step 3.4 Record: `git log --author='Chen Wandun' -10 linux-next/master
-- kernel/cgroup/cpuset.c mm/page_alloc.c` found this commit and one
unrelated page allocator simplification. The author is not shown as the
subsystem maintainer in the checked history; the patch was acked/applied
by cgroup maintainers/reviewers.

Step 3.5 Record: No functional prerequisite found. Older stable branches
may need the function-name/context adjusted because the function is
named `cpuset_node_allowed()` or `__cpuset_node_allowed()` there.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c dde2f938d02f2` found the original
submission:
`https://patch.msgid.link/20260507105434.3266234-1-
chenwandun@lixiang.com`
`b4 dig -a` found only v1.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to Chen Wandun,
Waiman Long, Chen Ridong, Tejun Heo, Johannes Weiner, Michal Koutný,
`cgroups@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Step 4.3 Record: No separate bug-report link or `Reported-by:` tag. The
thread includes Chen Ridong asking how it was found; the author replied
it was found while reviewing cpuset node-allowed logic during
investigation of a memory allocation issue, not as that investigation’s
root cause.

Step 4.4 Record: Thread review: Michal Koutný acked and said it “makes
sense,” while noting OOM could eventually select the task and bypass
hardwall, so this expedites rather than necessarily being the only
unblock. Waiman Long acked. Chen Ridong gave `Reviewed-by` in the
thread. Tejun Heo applied it to `cgroup/for-7.1-fixes`. No NAKs or
objections found.

Step 4.5 Record: WebFetch for lore/stable was blocked by Anubis;
WebSearch found no useful stable-specific objection or discussion. This
is an external-search limitation.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `cpuset_current_node_allowed()`.

Step 5.2 Record: Callers verified: `__cpuset_zone_allowed()` wraps it in
`include/linux/cpuset.h`; `get_page_from_freelist()` and reclaim retry
logic call `__cpuset_zone_allowed()` when cpusets are enabled and
`ALLOC_CPUSET` is set.

Step 5.3 Record: Key callees in `cpuset_current_node_allowed()` are
`in_interrupt()`, `node_isset()`, `tsk_is_oom_victim()`,
`nearest_hardwall_ancestor()`, `task_cs()`, and `spin_lock_irqsave()`
around ancestor scanning.

Step 5.4 Record: Reachability verified through the allocator:
`prepare_alloc_pages()` sets `__GFP_HARDWALL`;
`__alloc_frozen_pages_noprof()` calls `prepare_alloc_pages()` then
`get_page_from_freelist()`. `PF_EXITING` is set in `exit_signals()`
during `do_exit()` before later exit cleanup. I did not verify a
specific later cleanup function that always allocates; the allocator
path and `PF_EXITING` timing are verified.

Step 5.5 Record: Similar pattern found: `c596d9f320aa` allowed OOM-
killed tasks to allocate anywhere to avoid exit/deadlock problems, and
current `show_mem()` treats `PF_EXITING` as an exception allowed outside
node filters.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v4.4`, `v4.9`, `v4.14`, `v4.19`, `v5.4`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v7.0`; all checked trees
have the old ordering where `__GFP_HARDWALL` returns before
`PF_EXITING`, and allocator code setting/using `__GFP_HARDWALL`.

Step 6.2 Record: `git apply --check` of the upstream patch succeeds on
the current `v7.0.9` checkout with line offsets. Older branches need at
most minor context/name adjustment because the function name differs,
but the relevant body is present.

Step 6.3 Record: No separate alternative technical fix for this bug was
found by subject/bug-text searches. I did not use any branch-
selection/pipeline presence as decision evidence.

## Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is cgroup/cpuset with page allocator
interaction. Criticality is important to core: it affects memory
allocation behavior for systems using cpusets, especially NUMA/cgroup-
managed systems.

Step 7.2 Record: The cpuset file has active recent development, but the
affected allocation policy logic is mature and present across many
stable-era tags.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with cpusets enabled where
exiting tasks allocate while outside their allowed memory nodes or while
their allowed nodes are depleted. This is config/setup-specific, not
universal.

Step 8.2 Record: Trigger requires `PF_EXITING`, cpusets enabled, and an
allocation path where hardwall cpuset filtering checks a node outside
`current->mems_allowed`. Exiting is user-triggerable, but cpuset
placement usually depends on administrator/container-manager
configuration.

Step 8.3 Record: Failure mode is high severity: direct reclaim stalls
and possible OOM while a task is trying to exit. The thread reviewer
caveat means this may expedite exit in some OOM cases rather than prove
every instance is permanently stuck, but the liveness benefit is real.

Step 8.4 Record: Benefit is high for affected systems; risk is very low
because the change is a two-line ordering fix plus comments and only
broadens allocation eligibility for dying tasks.

## Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting: fixes a real allocation/liveness bug; small
one-function change; no API or feature addition; acknowledged by cgroup
reviewers; present in many stable-era tags; clean on `v7.0`; older trees
have the same logic.
Evidence against: no explicit `Fixes:`/`Cc: stable`/`Reported-
by`/`Tested-by`; no concrete reproducer in commit or thread; older trees
may need minor context adjustment.
Unresolved: I could not use WebFetch on lore/stable due Anubis; I did
not verify behavior earlier than `v4.4`; I did not run runtime tests.

Step 9.2 Stable rules:
1. Obviously correct and tested? Obviously correct by inspection; no
   explicit test tag.
2. Fixes a real bug? Yes, unreachable `PF_EXITING` allocation escape
   under hardwall cpuset filtering.
3. Important issue? Yes, can cause direct reclaim stalls or OOM during
   task exit.
4. Small and contained? Yes, one file, one function, 8 insertions/6
   deletions mostly comments.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for current `v7.0`; older trees likely need
   minor backport context due function naming.

Step 9.3 Exception category: No special exception category; this is a
normal bug fix.

Step 9.4 Decision: Backport. The fix restores intended dying-task
allocation behavior, is narrowly scoped, has strong reviewer confidence,
and addresses a serious liveness failure with minimal regression risk.

## Verification
- Phase 1: Parsed `git show --format=fuller` for `dde2f938d02f2`;
  confirmed tags and absence of `Fixes:`/`Reported-by:`/`Tested-by:`.
- Phase 2: Inspected the diff; confirmed only `kernel/cgroup/cpuset.c`
  changes and functional reorder in `cpuset_current_node_allowed()`.
- Phase 3: Ran `git blame` on `kernel/cgroup/cpuset.c` and
  `mm/page_alloc.c`; inspected historical commits `5563e77078d8`,
  `c596d9f320aa`, `9bf2229f8817`, `9cd7555875bb`, and `8adce0857769`.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and saved/read the
  mbox; confirmed v1 only, maintainer/reviewer acks, and no NAKs.
- Phase 5: Used repository search and file reads to trace
  `cpuset_current_node_allowed()` through `__cpuset_zone_allowed()` into
  `get_page_from_freelist()` and allocator preparation.
- Phase 6: Used `git grep` on stable tags from `v4.4` through `v7.0`;
  confirmed the old ordering and allocator hardwall behavior exist. Ran
  `git apply --check` successfully on current `v7.0.9`.
- Phase 7: Checked recent cpuset history to assess activity and context.
- Phase 8: Verified `PF_EXITING` is set in `exit_signals()` during
  `do_exit()` before later exit cleanup.
- UNVERIFIED: Lore/stable WebFetch was blocked by Anubis; no runtime
  reproducer or test result was found; exact pre-`v4.4` introduction was
  not verified.

**YES**

 kernel/cgroup/cpuset.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 1335e437098e8..d2d2c7126638a 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -4171,11 +4171,11 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
  * current's mems_allowed, yes.  If it's not a __GFP_HARDWALL request and this
  * node is set in the nearest hardwalled cpuset ancestor to current's cpuset,
  * yes.  If current has access to memory reserves as an oom victim, yes.
- * Otherwise, no.
+ * If the current task is PF_EXITING, yes. Otherwise, no.
  *
  * GFP_USER allocations are marked with the __GFP_HARDWALL bit,
  * and do not allow allocations outside the current tasks cpuset
- * unless the task has been OOM killed.
+ * unless the task has been OOM killed or is exiting.
  * GFP_KERNEL allocations are not so marked, so can escape to the
  * nearest enclosing hardwalled ancestor cpuset.
  *
@@ -4189,7 +4189,9 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
  * The first call here from mm/page_alloc:get_page_from_freelist()
  * has __GFP_HARDWALL set in gfp_mask, enforcing hardwall cpusets,
  * so no allocation on a node outside the cpuset is allowed (unless
- * in interrupt, of course).
+ * in interrupt, of course).  The PF_EXITING check must therefore
+ * come before the __GFP_HARDWALL check, otherwise a dying task
+ * would be blocked on the fast path.
  *
  * The second pass through get_page_from_freelist() doesn't even call
  * here for GFP_ATOMIC calls.  For those calls, the __alloc_pages()
@@ -4199,6 +4201,7 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
  *	in_interrupt - any node ok (current task context irrelevant)
  *	GFP_ATOMIC   - any node ok
  *	tsk_is_oom_victim   - any node ok
+ *	PF_EXITING   - any node ok (let dying task exit quickly)
  *	GFP_KERNEL   - any node in enclosing hardwalled cpuset ok
  *	GFP_USER     - only nodes in current tasks mems allowed ok.
  */
@@ -4218,11 +4221,10 @@ bool cpuset_current_node_allowed(int node, gfp_t gfp_mask)
 	 */
 	if (unlikely(tsk_is_oom_victim(current)))
 		return true;
-	if (gfp_mask & __GFP_HARDWALL)	/* If hardwall request, stop here */
-		return false;
-
 	if (current->flags & PF_EXITING) /* Let dying task have memory */
 		return true;
+	if (gfp_mask & __GFP_HARDWALL)	/* If hardwall request, stop here */
+		return false;
 
 	/* Not hardwall and node outside mems_allowed: scan up cpusets */
 	spin_lock_irqsave(&callback_lock, flags);
-- 
2.53.0