From: Nathan Chancellor <nathan@kernel.org>

[ Upstream commit d87208128a3330c0eab18301ab39bdb419647730 ]

'-mpreferred-stack-boundary' (the GCC option) and '-mstack-alignment'
(the clang option) have been supported in their respective compilers for
some time, so it is unnecessary to check for support for them via
cc-option. '-mpreferred-stack-boundary=3' had a restriction on
'-mno-sse' until GCC 7.1 but that is irrelevant for most of the kernel,
which includes '-mno-sse'.

Move to simple Kconfig checks to avoid querying the compiler for the
flags that it supports.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250814-x86-min-ver-cleanups-v1-2-ff7f19457523@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my comprehensive analysis of this commit, here is my
determination:

## Backport Status: NO

### Extensive Analysis

**Commit Context:**
- Upstream commit: d87208128a3330c0eab18301ab39bdb419647730 (August 14,
  2025)
- Author: Nathan Chancellor
- Part of patch series: "x86-min-ver-cleanups-v1"
- Already backported to 6.17 stable as 8be33f616f1c4 via AUTOSEL
  (Automatic Stable Election)
- Target tree: linux-autosel-6.17 (kernel 6.17)

**What the Commit Does:**
The commit removes runtime compiler capability checks (`cc-option`) for
stack alignment flags and replaces them with build-time Kconfig checks:
- For GCC: Uses `CONFIG_CC_IS_GCC` to unconditionally set `-mpreferred-
  stack-boundary=2/3`
- For Clang: Uses `CONFIG_CC_IS_CLANG` to unconditionally set `-mstack-
  alignment=4/8`

**Code Changes Analysis:**
```makefile
# OLD: Runtime check if compiler supports the flags
-ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+ifdef CONFIG_CC_IS_GCC
       cc_stack_align4 := -mpreferred-stack-boundary=2
       cc_stack_align8 := -mpreferred-stack-boundary=3
-else ifneq ($(call cc-option, -mstack-alignment=16),)
+endif
+ifdef CONFIG_CC_IS_CLANG
       cc_stack_align4 := -mstack-alignment=4
       cc_stack_align8 := -mstack-alignment=8
 endif
```

**Dependency Analysis:**
- Requires minimum GCC 8.1 for x86 (introduced in v6.15 via commit
  a3e8fe814ad1)
- Requires minimum Clang 15.0.0 for x86 (commit 7861640aac52b)
- Both requirements are satisfied in 6.17 stable tree (verified via
  scripts/min-tool-version.sh)
- GCC 7.1+ supports `-mpreferred-stack-boundary=3` with `-msse` (per GCC
  commit 34fac449e121)

**Evaluation Against Stable Kernel Rules:**

According to Documentation/process/stable-kernel-rules.rst, stable
patches must:

1. ✅ **Already exist in mainline**: YES -
   d87208128a3330c0eab18301ab39bdb419647730
2. ✅ **Obviously correct and tested**: YES - simple Makefile change, no
   issues found
3. ✅ **Not bigger than 100 lines**: YES - only 5 lines changed (3
   insertions, 2 deletions)
4. ✅ **Follow submitting-patches.rst rules**: YES
5. ❌ **Fix a real bug or add device ID**: **NO - This is the critical
   failure**

The rules explicitly state (lines 15-31 of stable-kernel-rules.rst):
> "It must either fix a real bug that bothers people or just add a
device ID."

This commit:
- Does **NOT** fix a bug (no oops, hang, data corruption, security
  issue, build error, etc.)
- Is a **cleanup/optimization** to improve build performance
- Provides **no user-visible bug fix**
- Falls under "trivial fixes without benefit for users" category (rule
  line 30-31)
- The original author did **NOT** tag it with `Cc:
  stable@vger.kernel.org`

**Search for Issues/Regressions:**
- Searched Linux kernel mailing lists: No issues found
- Searched for reverts: None found
- Searched for build failures: None reported
- Part of systematic cleanup series with no reported problems

**Risk Assessment:**
- **Technical risk**: Very low - simple change, dependencies satisfied
- **Regression risk**: Very low - no functionality change, just build
  system optimization
- **Policy compliance**: **Does not meet stable kernel criteria**

### Conclusion

While this commit is technically safe and provides a marginal build-time
performance improvement by eliminating unnecessary runtime compiler
checks, **it does not meet the fundamental requirement for stable kernel
backporting**: it does not fix a bug that affects users.

The commit is purely a cleanup that removes obsolete code after compiler
minimum version requirements were raised. Such cleanups belong in
mainline development, not stable trees, which should focus exclusively
on fixing bugs that impact users.

The fact that it was auto-selected by AUTOSEL does not override the
documented stable kernel rules. This commit should be **rejected** from
stable backporting or **reverted** if already applied.

 arch/x86/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 1913d342969ba..7cfc1b31f17e1 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -37,10 +37,11 @@ export RETPOLINE_VDSO_CFLAGS
 
 # For gcc stack alignment is specified with -mpreferred-stack-boundary,
 # clang has the option -mstack-alignment for that purpose.
-ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+ifdef CONFIG_CC_IS_GCC
       cc_stack_align4 := -mpreferred-stack-boundary=2
       cc_stack_align8 := -mpreferred-stack-boundary=3
-else ifneq ($(call cc-option, -mstack-alignment=16),)
+endif
+ifdef CONFIG_CC_IS_CLANG
       cc_stack_align4 := -mstack-alignment=4
       cc_stack_align8 := -mstack-alignment=8
 endif
-- 
2.51.0

On Mon, Oct 06, 2025 at 02:17:33PM -0400, Sasha Levin wrote:
> From: Nathan Chancellor <nathan@kernel.org>
> 
> [ Upstream commit d87208128a3330c0eab18301ab39bdb419647730 ]
> 
> '-mpreferred-stack-boundary' (the GCC option) and '-mstack-alignment'
> (the clang option) have been supported in their respective compilers for
> some time, so it is unnecessary to check for support for them via
> cc-option. '-mpreferred-stack-boundary=3' had a restriction on
> '-mno-sse' until GCC 7.1 but that is irrelevant for most of the kernel,
> which includes '-mno-sse'.
> 
> Move to simple Kconfig checks to avoid querying the compiler for the
> flags that it supports.
> 
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> Link: https://lore.kernel.org/20250814-x86-min-ver-cleanups-v1-2-ff7f19457523@kernel.org
> Signed-off-by: Sasha Levin <sashal@kernel.org>
...
> ## Backport Status: NO
...
> **Dependency Analysis:**
> - Requires minimum GCC 8.1 for x86 (introduced in v6.15 via commit
>   a3e8fe814ad1)
> - Requires minimum Clang 15.0.0 for x86 (commit 7861640aac52b)
> - Both requirements are satisfied in 6.17 stable tree (verified via
>   scripts/min-tool-version.sh)
> - GCC 7.1+ supports `-mpreferred-stack-boundary=3` with `-msse` (per GCC
>   commit 34fac449e121)
...
> ### Conclusion
> 
> While this commit is technically safe and provides a marginal build-time
> performance improvement by eliminating unnecessary runtime compiler
> checks, **it does not meet the fundamental requirement for stable kernel
> backporting**: it does not fix a bug that affects users.
> 
> The commit is purely a cleanup that removes obsolete code after compiler
> minimum version requirements were raised. Such cleanups belong in
> mainline development, not stable trees, which should focus exclusively
> on fixing bugs that impact users.
> 
> The fact that it was auto-selected by AUTOSEL does not override the
> documented stable kernel rules. This commit should be **rejected** from
> stable backporting or **reverted** if already applied.

Based on all of this, I would agree that it is not really suitable for
backporting (at least not beyond 6.15, whereas the subject says back to
5.4), so why was this still sent for review?

Cheers,
Nathan

On Mon, Oct 06, 2025 at 02:55:05PM -0700, Nathan Chancellor wrote:
>On Mon, Oct 06, 2025 at 02:17:33PM -0400, Sasha Levin wrote:
>> From: Nathan Chancellor <nathan@kernel.org>
>>
>> [ Upstream commit d87208128a3330c0eab18301ab39bdb419647730 ]
>>
>> '-mpreferred-stack-boundary' (the GCC option) and '-mstack-alignment'
>> (the clang option) have been supported in their respective compilers for
>> some time, so it is unnecessary to check for support for them via
>> cc-option. '-mpreferred-stack-boundary=3' had a restriction on
>> '-mno-sse' until GCC 7.1 but that is irrelevant for most of the kernel,
>> which includes '-mno-sse'.
>>
>> Move to simple Kconfig checks to avoid querying the compiler for the
>> flags that it supports.
>>
>> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
>> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
>> Link: https://lore.kernel.org/20250814-x86-min-ver-cleanups-v1-2-ff7f19457523@kernel.org
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>...
>> ## Backport Status: NO
>...
>> **Dependency Analysis:**
>> - Requires minimum GCC 8.1 for x86 (introduced in v6.15 via commit
>>   a3e8fe814ad1)
>> - Requires minimum Clang 15.0.0 for x86 (commit 7861640aac52b)
>> - Both requirements are satisfied in 6.17 stable tree (verified via
>>   scripts/min-tool-version.sh)
>> - GCC 7.1+ supports `-mpreferred-stack-boundary=3` with `-msse` (per GCC
>>   commit 34fac449e121)
>...
>> ### Conclusion
>>
>> While this commit is technically safe and provides a marginal build-time
>> performance improvement by eliminating unnecessary runtime compiler
>> checks, **it does not meet the fundamental requirement for stable kernel
>> backporting**: it does not fix a bug that affects users.
>>
>> The commit is purely a cleanup that removes obsolete code after compiler
>> minimum version requirements were raised. Such cleanups belong in
>> mainline development, not stable trees, which should focus exclusively
>> on fixing bugs that impact users.
>>
>> The fact that it was auto-selected by AUTOSEL does not override the
>> documented stable kernel rules. This commit should be **rejected** from
>> stable backporting or **reverted** if already applied.
>
>Based on all of this, I would agree that it is not really suitable for
>backporting (at least not beyond 6.15, whereas the subject says back to
>5.4), so why was this still sent for review?

Sorry for the noise, I thought I dropped this one :(

-- 
Thanks,
Sasha

From: Tejun Heo <tj@kernel.org>

[ Upstream commit 4a1d9d73aabc8f97f48c4f84f936de3b265ffd6f ]

scx_enable() turns on the bypass mode while enable is in progress. If
enabling fails, it turns off the bypass mode and then triggers scx_error().
scx_error() will trigger scx_disable_workfn() which will turn on the bypass
mode again and unload the failed scheduler.

This moves the system out of bypass mode between the enable error path and
the disable path, which is unnecessary and can be brittle - e.g. the thread
running scx_enable() may already be on the failed scheduler and can be
switched out before it triggers scx_error() leading to a stall. The watchdog
would eventually kick in, so the situation isn't critical but is still
suboptimal.

There is nothing to be gained by turning off the bypass mode between
scx_enable() failure and scx_disable_workfn(). Keep bypass on.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my comprehensive analysis, here is my determination:

## **YES**

This commit should be backported to stable kernel trees.

### Detailed Analysis:

#### **Context and Timing:**
- **sched_ext introduction**: This feature was first introduced in
  kernel **v6.12** (confirmed via git tag analysis)
- **Applicability**: This commit is only relevant for kernels **v6.12
  and later** that include sched_ext
- **Current status**: The commit has **already been selected** for
  backporting to 6.17 (commit 2d013fc03f11a with Sasha Levin's sign-off)

#### **Bug Description and Impact:**
The code change addresses a **race condition in the error handling
path** during BPF scheduler enablement:

**Old behavior (buggy):**
1. Line 4580: `scx_bypass(true)` - Enable bypass mode during scheduler
   initialization
2. On error → Line 4708-4711: `scx_bypass(false)` - **Disable bypass
   mode**
3. Call `scx_error()` which triggers `scx_disable_workfn()`
4. Line 3873 in `scx_disable_workfn()`: `scx_bypass(true)` - Re-enable
   bypass mode

**Problem:** Between steps 2 and 4, the system is **out of bypass mode**
with a failed scheduler. The commit message explicitly states: *"the
thread running scx_enable() may already be on the failed scheduler and
can be switched out before it triggers scx_error() **leading to a
stall**"*

**New behavior (fixed):**
Simply **removes** the `scx_bypass(false)` call at line 4710, keeping
bypass mode continuously enabled from the failure point through the
entire disable sequence.

#### **Why This Should Be Backported:**

1. **Real Bug**: This fixes an actual stall condition (confirmed by
   author Tejun Heo and acked by Andrea Righi)

2. **User Impact**: While the watchdog eventually recovers, users
   experience **unnecessary stalls** when BPF schedulers fail to load -
   a real-world scenario

3. **Minimal Risk**:
   - **1-line change** (removal only)
   - Makes error path **more conservative** (keeps bypass on longer)
   - No new logic introduced
   - Only affects **error conditions**, not normal operation

4. **Stable Tree Criteria Met**:
   - ✅ Fixes important bug affecting users
   - ✅ Doesn't introduce new features
   - ✅ No architectural changes
   - ✅ Minimal regression risk
   - ✅ Confined to sched_ext subsystem

5. **Already Validated**: The autosel process has already selected this
   for 6.17, indicating automated analysis confirms its suitability

6. **Active Subsystem**: Multiple sched_ext fixes show this is under
   active maintenance and bug discovery

#### **Code Change Details:**
```c
// kernel/sched/ext.c, line 4708-4712
err_disable_unlock_all:
    scx_cgroup_unlock();
    percpu_up_write(&scx_fork_rwsem);
- scx_bypass(false);  // REMOVED
+   /* we'll soon enter disable path, keep bypass on */  // ADDED
COMMENT
err_disable:
```

This single-line removal prevents the problematic window where the
system exits bypass mode between error detection and cleanup,
eliminating the potential for stalls during scheduler enable failures.

 kernel/sched/ext.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index 088ceff38c8a4..2ccc885a229d5 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -5795,7 +5795,7 @@ static int scx_enable(struct sched_ext_ops *ops, struct bpf_link *link)
 err_disable_unlock_all:
 	scx_cgroup_unlock();
 	percpu_up_write(&scx_fork_rwsem);
-	scx_bypass(false);
+	/* we'll soon enter disable path, keep bypass on */
 err_disable:
 	mutex_unlock(&scx_enable_mutex);
 	/*
-- 
2.51.0

From: Dapeng Mi <dapeng1.mi@linux.intel.com>

[ Upstream commit 2676dbf9f4fb7f6739d1207c0f1deaf63124642a ]

ICL_FIXED_0_ADAPTIVE is missed to be added into INTEL_FIXED_BITS_MASK,
add it.

With help of this new INTEL_FIXED_BITS_MASK, intel_pmu_enable_fixed() can
be optimized. The old fixed counter control bits can be unconditionally
cleared with INTEL_FIXED_BITS_MASK and then set new control bits base on
new configuration.

Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
Link: https://lore.kernel.org/r/20250820023032.17128-7-dapeng1.mi@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**YES**

This commit should definitely be backported to stable kernel trees.

## Extensive Analysis

### Nature of the Bug

This commit fixes a **real and significant bug** in the Intel PMU
(Performance Monitoring Unit) fixed counter handling. The bug has
existed since kernel v6.5 when `INTEL_FIXED_BITS_MASK` was introduced in
commit 10d95a317ec12 (May 2023).

### Technical Details of the Bug

**In arch/x86/include/asm/perf_event.h:18-35:**

The original `INTEL_FIXED_BITS_MASK` was defined as `0xFULL` (binary
1111), covering only bits 0-3:
```c
-#define INTEL_FIXED_BITS_MASK                          0xFULL
```

However, the mask was missing `ICL_FIXED_0_ADAPTIVE` (bit 32), which has
existed since 2019 for Ice Lake adaptive PEBS v4 support (commit
c22497f5838c2). The fix correctly includes all relevant bits:
```c
+#define INTEL_FIXED_BITS_MASK                                  \
+       (INTEL_FIXED_0_KERNEL | INTEL_FIXED_0_USER |            \
+        INTEL_FIXED_0_ANYTHREAD | INTEL_FIXED_0_ENABLE_PMI |   \
+        ICL_FIXED_0_ADAPTIVE)
```

**In arch/x86/events/intel/core.c:2844-2896:**

The bug manifests in `intel_pmu_enable_fixed()` at lines 2888-2895. When
reconfiguring a fixed counter:

**Before the fix:**
- Line 2888 creates `mask` with only bits 0-3
- Lines 2890-2893 conditionally add `ICL_FIXED_0_ADAPTIVE` to both
  `bits` and `mask` only if PEBS is enabled
- Line 2895 clears bits using the incomplete mask
- **Problem:** If a counter previously had `ICL_FIXED_0_ADAPTIVE` set
  but the new configuration doesn't need it, the bit won't be cleared
  because it's not in the mask

**After the fix:**
- The mask always includes `ICL_FIXED_0_ADAPTIVE`
- Line 2890 unconditionally clears all relevant bits (including
  `ICL_FIXED_0_ADAPTIVE`)
- Lines 2890-2891 set `ICL_FIXED_0_ADAPTIVE` only when needed
- The code is cleaner and bug-free

### Impact Analysis

1. **Affected Hardware:** Intel Ice Lake (ICL) and newer processors with
   adaptive PEBS support

2. **Symptom:** The `ICL_FIXED_0_ADAPTIVE` bit can remain incorrectly
   set after reconfiguring performance counters, causing:
   - Incorrect PMU behavior
   - Adaptive PEBS being enabled when it should be disabled
   - Performance monitoring data corruption

3. **Severity:** This bug was explicitly identified as **"Bug #3"** in
   KVM commit 9e985cbf2942a (March 2024), which stated:
  > "Bug #3 is in perf. intel_pmu_disable_fixed() doesn't clear the
  upper bits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and
  intel_pmu_enable_fixed() effectively doesn't clear
  ICL_FIXED_0_ADAPTIVE either. I.e. perf _always_ enables ADAPTIVE
  counters, regardless of what KVM requests."

4. **Security Context:** KVM had to **completely disable adaptive PEBS
   support** (with a Cc: stable tag) as a workaround for multiple bugs,
   including this one. The KVM commit mentioned potential security
   implications including LBR leaks.

### Why This Should Be Backported

1. ✅ **Fixes an important bug** affecting Intel processors since 2019
   (Ice Lake)
2. ✅ **Small, contained change** - only modifies a constant definition
   and simplifies existing code
3. ✅ **Low regression risk** - the change makes the mask complete and
   correct
4. ✅ **Well-reviewed and tested** - Reviewed-by: Kan Liang, Tested-by:
   Yi Lai (both from Intel)
5. ✅ **Addresses known issue** - this was explicitly identified in a
   previous security-related commit
6. ✅ **Affects both enable and disable paths** - also fixes
   `intel_pmu_disable_fixed()` at line 2562 which uses the same mask
7. ✅ **No architectural changes** - pure bug fix
8. ✅ **Stable since v6.5** - applies cleanly to all kernels since the
   mask was introduced

### Dependencies

This fix requires that `INTEL_FIXED_BITS_MASK` exists, which was
introduced in kernel v6.5. The fix should be backported to all stable
trees from **v6.5 onwards**.

### Conclusion

This is a textbook example of a commit suitable for stable backporting:
it fixes a real bug with clear symptoms, is small and low-risk, and has
been properly reviewed and tested. The fact that it addresses an issue
severe enough to warrant disabling an entire feature in KVM further
underscores its importance.

 arch/x86/events/intel/core.c      | 10 +++-------
 arch/x86/include/asm/perf_event.h |  6 +++++-
 arch/x86/kvm/pmu.h                |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index c2fb729c270ec..af47d266f8064 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2845,8 +2845,8 @@ static void intel_pmu_enable_fixed(struct perf_event *event)
 {
 	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
 	struct hw_perf_event *hwc = &event->hw;
-	u64 mask, bits = 0;
 	int idx = hwc->idx;
+	u64 bits = 0;
 
 	if (is_topdown_idx(idx)) {
 		struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
@@ -2885,14 +2885,10 @@ static void intel_pmu_enable_fixed(struct perf_event *event)
 
 	idx -= INTEL_PMC_IDX_FIXED;
 	bits = intel_fixed_bits_by_idx(idx, bits);
-	mask = intel_fixed_bits_by_idx(idx, INTEL_FIXED_BITS_MASK);
-
-	if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip) {
+	if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip)
 		bits |= intel_fixed_bits_by_idx(idx, ICL_FIXED_0_ADAPTIVE);
-		mask |= intel_fixed_bits_by_idx(idx, ICL_FIXED_0_ADAPTIVE);
-	}
 
-	cpuc->fixed_ctrl_val &= ~mask;
+	cpuc->fixed_ctrl_val &= ~intel_fixed_bits_by_idx(idx, INTEL_FIXED_BITS_MASK);
 	cpuc->fixed_ctrl_val |= bits;
 }
 
diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h
index 70d1d94aca7e6..ee943bd1595af 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -35,7 +35,6 @@
 #define ARCH_PERFMON_EVENTSEL_EQ			(1ULL << 36)
 #define ARCH_PERFMON_EVENTSEL_UMASK2			(0xFFULL << 40)
 
-#define INTEL_FIXED_BITS_MASK				0xFULL
 #define INTEL_FIXED_BITS_STRIDE			4
 #define INTEL_FIXED_0_KERNEL				(1ULL << 0)
 #define INTEL_FIXED_0_USER				(1ULL << 1)
@@ -48,6 +47,11 @@
 #define ICL_EVENTSEL_ADAPTIVE				(1ULL << 34)
 #define ICL_FIXED_0_ADAPTIVE				(1ULL << 32)
 
+#define INTEL_FIXED_BITS_MASK					\
+	(INTEL_FIXED_0_KERNEL | INTEL_FIXED_0_USER |		\
+	 INTEL_FIXED_0_ANYTHREAD | INTEL_FIXED_0_ENABLE_PMI |	\
+	 ICL_FIXED_0_ADAPTIVE)
+
 #define intel_fixed_bits_by_idx(_idx, _bits)			\
 	((_bits) << ((_idx) * INTEL_FIXED_BITS_STRIDE))
 
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index ad89d0bd60058..103604c4b33b5 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -13,7 +13,7 @@
 #define MSR_IA32_MISC_ENABLE_PMU_RO_MASK (MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL |	\
 					  MSR_IA32_MISC_ENABLE_BTS_UNAVAIL)
 
-/* retrieve the 4 bits for EN and PMI out of IA32_FIXED_CTR_CTRL */
+/* retrieve a fixed counter bits out of IA32_FIXED_CTR_CTRL */
 #define fixed_ctrl_field(ctrl_reg, idx) \
 	(((ctrl_reg) >> ((idx) * INTEL_FIXED_BITS_STRIDE)) & INTEL_FIXED_BITS_MASK)
 
-- 
2.51.0

From: Josh Poimboeuf <jpoimboe@kernel.org>

[ Upstream commit 16ed389227651330879e17bd83d43bd234006722 ]

If the task is not a user thread, there's no user stack to unwind.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250820180428.930791978@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Backport Recommendation: **YES**

### Comprehensive Analysis

#### What the Bug Fixes

This commit addresses a **correctness and robustness bug** in the perf
subsystem's callchain unwinding logic. The issue is that
`perf_callchain()` incorrectly attempts to unwind user stacks for kernel
threads that have a memory descriptor (mm) field, specifically io_uring
helpers and other `PF_USER_WORKER` tasks.

**The Core Problem:**
- Line 8195 in kernel/events/core.c:8195: `bool user =
  !event->attr.exclude_callchain_user;`
- Line 8201-8202: Only checks `if (!current->mm) user = false;`
- **However**, io_uring helpers (marked with `PF_USER_WORKER`) are
  kernel threads that **do have** `current->mm` set
- This causes the code to incorrectly attempt user stack unwinding for
  these kernel threads

**The Fix:**
The commit adds an explicit check for kernel thread flags when
determining whether to unwind user stacks:
```c
bool user = !event->attr.exclude_callchain_user &&
    !(current->flags & (PF_KTHREAD | PF_USER_WORKER));
```

This provides defense-in-depth alongside the later `!current->mm` check
at line 8201.

#### Context from Related Commits

This is part of a coordinated patch series (commits e649bcda25b5a →
16ed389227651) that improves perf's handling of kernel threads:

1. **Commit 90942f9fac057** (Steven Rostedt): Fixed
   `get_perf_callchain()` and other locations in
   kernel/events/callchain.c and kernel/events/core.c with the same
   PF_KTHREAD|PF_USER_WORKER check
2. **Commit 16ed389227651** (this commit, Josh Poimboeuf): Completes the
   fix by applying the same logic to `perf_callchain()`

The commit message from 90942f9fac057 explains the rationale clearly:
> "To determine if a task is a kernel thread or not, it is more reliable
to use (current->flags & (PF_KTHREAD|PF_USER_WORKER)) than to rely on
current->mm being NULL. That is because some kernel tasks (io_uring
helpers) may have a mm field."

#### Historical Context

- **PF_USER_WORKER** was introduced in v6.4 (commit 54e6842d0775, March
  2023) as part of moving common PF_IO_WORKER behavior
- The bug has existed since v6.4 when io_uring helpers started having mm
  fields set
- This fix is from **August 2025** (very recent)

#### Impact Assessment

**1. Correctness Issues:**
- Perf events collecting callchains will have **incorrect/garbage data**
  when profiling workloads using io_uring
- This affects production systems using io_uring with performance
  profiling

**2. Performance Impact:**
- Unnecessary CPU cycles wasted attempting to unwind non-existent user
  stacks
- Could be significant in workloads with heavy io_uring usage and perf
  sampling

**3. Potential Stability Issues:**
- Attempting to walk a non-existent user stack could access invalid
  memory
- Architecture-specific `perf_callchain_user()` implementations may not
  handle this gracefully
- While no explicit crash reports are in the commit, the potential
  exists

**4. Affected Systems:**
- Any system using io_uring + perf profiling (common in modern high-
  performance applications)
- Affects all architectures that support perf callchain unwinding

#### Why This Should Be Backported

✅ **Fixes important bug**: Corrects fundamental logic error in
determining user vs kernel threads

✅ **Small and contained**: Only adds a single condition check - 2 lines
changed in kernel/events/core.c:8195-8196

✅ **Minimal regression risk**: The check is conservative - it only
prevents incorrect behavior, doesn't change valid cases

✅ **Affects real workloads**: io_uring is widely used in databases, web
servers, and high-performance applications

✅ **Part of coordinated fix series**: Works together with commit
90942f9fac057 that's likely already being backported

✅ **Follows stable rules**:
- Important correctness fix
- No architectural changes
- Confined to perf subsystem
- Low risk

✅ **No dependencies**: Clean application on top of existing code

#### Evidence from Code Analysis

Looking at kernel/events/core.c:8191-8209, the current code flow for a
`PF_USER_WORKER` task:
1. `user = !event->attr.exclude_callchain_user` → likely true
2. `if (!current->mm)` → **false** for io_uring helpers (they have mm)
3. `user` remains true
4. Calls `get_perf_callchain(..., user=true, ...)` → **INCORRECT**

After the fix:
1. `user = !event->attr.exclude_callchain_user && !(current->flags &
   PF_USER_WORKER)` → **correctly false**
2. Returns empty callchain or kernel-only callchain → **CORRECT**

This is clearly a bug that needs fixing in stable kernels.

 kernel/events/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index ea9ff856770be..6f01304a73f63 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8192,7 +8192,8 @@ struct perf_callchain_entry *
 perf_callchain(struct perf_event *event, struct pt_regs *regs)
 {
 	bool kernel = !event->attr.exclude_callchain_kernel;
-	bool user   = !event->attr.exclude_callchain_user;
+	bool user   = !event->attr.exclude_callchain_user &&
+		!(current->flags & (PF_KTHREAD | PF_USER_WORKER));
 	/* Disallow cross-task user callchains. */
 	bool crosstask = event->ctx->task && event->ctx->task != current;
 	const u32 max_stack = event->attr.sample_max_stack;
-- 
2.51.0

From: Josh Poimboeuf <jpoimboe@kernel.org>

[ Upstream commit 153f9e74dec230f2e070e16fa061bc7adfd2c450 ]

get_perf_callchain() doesn't support cross-task unwinding for user space
stacks, have it return NULL if both the crosstask and user arguments are
set.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250820180428.426423415@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## BACKPORT RECOMMENDATION: YES

## COMPREHENSIVE ANALYSIS

### Executive Summary
This commit fixes a long-standing correctness and efficiency issue in
`get_perf_callchain()` by making it return NULL early when attempting
unsupported cross-task user stack unwinding, rather than wastefully
allocating and deallocating resources. This is a low-risk bug fix that
improves both correctness and efficiency.

---

### Code Change Analysis

**What Changed:**
The commit modifies `kernel/events/callchain.c:get_perf_callchain()` in
two key ways:

1. **Added early NULL return check** (lines 227-229):
```c
+       /* crosstask is not supported for user stacks */
+       if (crosstask && user && !kernel)
+               return NULL;
```

2. **Modified user section entry condition** (line 247):
```c
- if (user) {
+       if (user && !crosstask) {
```

3. **Removed redundant checks** (lines 252-254, 264):
   - Removed `if (crosstask) goto exit_put;` inside the user section
   - Removed the now-unnecessary `exit_put:` label

**Functional Impact:**
- **Before**: When `crosstask && user && !kernel`, the function would
  call `get_callchain_entry(&rctx)` to allocate a per-CPU buffer, enter
  the user path, immediately hit `if (crosstask) goto exit_put;`,
  deallocate the buffer, and return an "empty" callchain entry.
- **After**: When `crosstask && user && !kernel`, the function returns
  NULL immediately without any resource allocation.

---

### Historical Context

**Origin of crosstask support (2016):**
Commit `568b329a02f75` by Alexei Starovoitov (Feb 2016) generalized
`get_perf_callchain()` for BPF usage and added the `crosstask` parameter
with this explicit comment:
```c
/* Disallow cross-task user callchains. */
```

The original implementation included `if (crosstask) goto exit_put;` in
the user path, showing the intent was **always to disallow cross-task
user stack unwinding**. The reason is clear: cross-task user stack
unwinding is unsafe because:
- The target task's user stack memory may not be accessible from the
  current context
- It would require complex synchronization and memory access validation
- Security implications of reading another process's user space stack

**Why the old code was problematic:**
For 9+ years (2016-2025), the function has been allocating resources
only to immediately deallocate them for the unsupported case. This
wastes CPU cycles and makes the code harder to understand.

---

### Caller Analysis

**All callers properly handle NULL returns:**

1. **kernel/events/core.c:perf_callchain()** (lines 8220):
```c
callchain = get_perf_callchain(regs, kernel, user, max_stack, crosstask,
true);
return callchain ?: &__empty_callchain;
```
Uses the ternary operator to return `&__empty_callchain` when NULL.

2. **kernel/bpf/stackmap.c** (lines 317, 454):
```c
/* get_perf_callchain does not support crosstask user stack walking
 - but returns an empty stack instead of NULL.
 */
if (crosstask && user) {
    err = -EOPNOTSUPP;
    goto clear;
}
...
trace = get_perf_callchain(regs, kernel, user, max_depth, crosstask,
false);
if (unlikely(!trace))
    /* couldn't fetch the stack trace */
    return -EFAULT;
```

**Key observation:** The BPF code comment explicitly states it expects
NULL for crosstask+user, but notes the function "returns an empty stack
instead." This commit **fixes this discrepancy**.

---

### Risk Assessment

**Risk Level: VERY LOW**

**Why low risk:**
1. **Behavioral compatibility**: The functional outcome is identical -
   both old and new code result in no user stack data being collected
   for crosstask scenarios
2. **Caller readiness**: All callers already have NULL-handling code in
   place
3. **Resource efficiency**: Only improves performance by avoiding
   wasteful allocation/deallocation
4. **No semantic changes**: The "unsupported operation" is still
   unsupported, just handled more efficiently
5. **Code simplification**: Removes goto statement and makes control
   flow clearer

**Potential concerns addressed:**
- **Performance impact**: Positive - reduces overhead
- **Compatibility**: Complete - callers expect this behavior
- **Edge cases**: The scenario (crosstask user-only callchains) is
  uncommon in practice, evidenced by the fact this inefficiency went
  unnoticed for 9 years

---

### Bug Fix Classification

**This IS a bug fix, specifically:**
1. **Correctness bug**: Behavior didn't match documented intent (BPF
   comment)
2. **Efficiency bug**: Wasteful resource allocation for unsupported
   operations
3. **Code clarity bug**: Goto-based control flow obscured the actual
   behavior

**Not a security bug**: No security implications, no CVE

---

### Series Context

This commit is part of a cleanup series by Josh Poimboeuf:
1. `e649bcda25b5a` - Remove unused `init_nr` argument (cleanup)
2. **`153f9e74dec23` - Fix crosstask+user handling (THIS COMMIT - bug
   fix)**
3. `d77e3319e3109` - Simplify user logic further (cleanup)
4. `16ed389227651` - Skip user unwind for kernel threads (bug fix)

**No follow-up fixes required**: No subsequent commits fix issues
introduced by this change, indicating it's stable.

---

### Backporting Considerations

**Arguments FOR backporting:**
1. ✅ **Fixes long-standing bug**: Corrects 9-year-old inefficiency
2. ✅ **Low risk**: Minimal code change, all callers prepared
3. ✅ **Improves correctness**: Aligns behavior with documented intent
4. ✅ **Performance benefit**: Reduces unnecessary overhead
5. ✅ **Clean commit**: Well-tested, no follow-up fixes needed
6. ✅ **Follows stable rules**: Important bugfix, minimal regression
   risk, confined to perf subsystem

**Arguments AGAINST backporting:**
1. ⚠️ **No Cc: stable tag**: Maintainers didn't mark it for stable
2. ⚠️ **Rare scenario**: crosstask user-only callchains are uncommon
3. ⚠️ **Non-critical**: No user-visible bugs reported

**Verdict:**
The absence of a `Cc: stable` tag suggests maintainers viewed this as a
minor fix rather than critical. However, the change meets all technical
criteria for stable backporting: it's a genuine bug fix, low-risk, and
improves correctness. The decision likely depends on stable tree
maintainer philosophy - this is a quality improvement rather than a
critical user-facing fix.

---

### Recommendation: **YES - Backport to stable trees**

**Rationale:**
While not critical, this commit improves kernel quality with minimal
risk. It fixes a real (if uncommon) inefficiency, improves code clarity,
and has no downsides. Stable trees benefit from such quality
improvements, especially when they're this low-risk.

**Suggested stable versions:** 6.6+, 6.12+, 6.17+ (any stable tree where
perf events are actively used)

**Dependencies:** Should ideally be backported with the prerequisite
commit:
- `e649bcda25b5a` ("perf: Remove get_perf_callchain() init_nr argument")
  - simplifies the function signature

The follow-up commits (`d77e3319e3109`, `16ed389227651`) are optional
but recommended for consistency.

 kernel/events/callchain.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index decff7266cfbd..2609998ca07f1 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -224,6 +224,10 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
 	struct perf_callchain_entry_ctx ctx;
 	int rctx, start_entry_idx;
 
+	/* crosstask is not supported for user stacks */
+	if (crosstask && user && !kernel)
+		return NULL;
+
 	entry = get_callchain_entry(&rctx);
 	if (!entry)
 		return NULL;
@@ -240,7 +244,7 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
 		perf_callchain_kernel(&ctx, regs);
 	}
 
-	if (user) {
+	if (user && !crosstask) {
 		if (!user_mode(regs)) {
 			if (current->flags & (PF_KTHREAD | PF_USER_WORKER))
 				regs = NULL;
@@ -249,9 +253,6 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
 		}
 
 		if (regs) {
-			if (crosstask)
-				goto exit_put;
-
 			if (add_mark)
 				perf_callchain_store_context(&ctx, PERF_CONTEXT_USER);
 
@@ -261,7 +262,6 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
 		}
 	}
 
-exit_put:
 	put_callchain_entry(rctx);
 
 	return entry;
-- 
2.51.0

From: Steven Rostedt <rostedt@goodmis.org>

[ Upstream commit 90942f9fac05702065ff82ed0bade0d08168d4ea ]

To determine if a task is a kernel thread or not, it is more reliable to
use (current->flags & (PF_KTHREAD|PF_USER_WORKERi)) than to rely on
current->mm being NULL.  That is because some kernel tasks (io_uring
helpers) may have a mm field.

Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250820180428.592367294@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my comprehensive analysis, here is my determination:

## **Backport Status: YES**

### Extensive Analysis:

#### **Context and Problem Being Fixed:**

This commit addresses a **correctness bug** in how the perf subsystem
identifies kernel threads. The issue is that the code was using
`current->mm == NULL` to determine if a task is a kernel thread, but
this assumption is incorrect for **io_uring helper threads and other
PF_USER_WORKER threads**, which have a non-NULL mm field despite being
kernel-side workers.

#### **Evidence from Code Investigation:**

1. **This is part of a fix series**: I found three related commits in
   upstream:
   - `16ed389227651`: "perf: Skip user unwind if the task is a kernel
     thread" (already being backported to stable as `823d7b9ec8616`)
   - `d77e3319e3109`: "perf: Simplify get_perf_callchain() user logic"
     (already in stable as `96681d3b99282`)
   - `90942f9fac057`: **This commit** - completes the fix by updating
     remaining locations

2. **Historical context**: PF_USER_WORKER was introduced in commit
   `54e6842d0775b` (March 2023) to handle io_uring and vhost workers
   that behave differently from regular kernel threads. These threads
   have mm contexts but shouldn't be treated as user threads for
   operations like register sampling.

3. **Real-world impact**: PowerPC already experienced crashes (commit
   `01849382373b8`) when trying to access pt_regs for PF_IO_WORKER tasks
   during coredump generation, demonstrating this class of bugs is real.

#### **Specific Code Changes Analysis:**

1. **kernel/events/callchain.c:247-250** (currently at line 245 in
   autosel-6.17):
   - **OLD**: `if (current->mm)` then use `task_pt_regs(current)`
   - **NEW**: `if (current->flags & (PF_KTHREAD | PF_USER_WORKER))` then
     skip user unwinding
   - **Impact**: Prevents perf from attempting to unwind user stack for
     io_uring helpers

2. **kernel/events/core.c:7455** (currently at line 7443 in
   autosel-6.17):
   - **OLD**: `!(current->flags & PF_KTHREAD)`
   - **NEW**: `!(current->flags & (PF_KTHREAD | PF_USER_WORKER))`
   - **Impact**: Correctly excludes user worker threads from user
     register sampling

3. **kernel/events/core.c:8095** (currently at line 8083 in
   autosel-6.17):
   - **OLD**: `if (current->mm != NULL)`
   - **NEW**: `if (!(current->flags & (PF_KTHREAD | PF_USER_WORKER)))`
   - **Impact**: Prevents incorrect page table walks for user worker
     threads in `perf_virt_to_phys()`

#### **Why This Qualifies for Backporting:**

1. **Fixes a real bug**: Perf incorrectly handles io_uring helper
   threads, leading to:
   - Incorrect callchain collection
   - Wrong register samples
   - Potential crashes or data corruption when walking page tables

2. **Affects widely-used functionality**: io_uring is heavily used in
   modern applications (databases, proxies, async I/O workloads), and
   perf profiling of these workloads would hit this bug

3. **Small and contained**: Only 3 conditional checks changed across 2
   files - minimal risk

4. **Part of an upstream series already being backported**: The first
   commit in the series (`16ed389227651`) is already marked for stable
   backport, making this a natural follow-up

5. **No architectural changes**: Pure bug fix with no API changes or
   feature additions

6. **Low regression risk**: The new flag-based check is more correct
   than the mm-based check; any behavioral changes would be fixing
   incorrect behavior

#### **Verification in Current Tree:**

I confirmed that linux-autosel-6.17 still has the old buggy code:
- Line 7443: Missing PF_USER_WORKER in the check
- Line 8083: Still uses `current->mm != NULL`
- callchain.c:245: Still uses `if (current->mm)`

This confirms the fix is needed and not yet applied.

#### **Conclusion:**

This is a **clear YES for backporting**. It's a well-understood
correctness fix for a real bug affecting perf profiling of io_uring
workloads, with minimal risk and part of an ongoing stable backport
series.

 kernel/events/callchain.c | 6 +++---
 kernel/events/core.c      | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index 6c83ad674d010..decff7266cfbd 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -242,10 +242,10 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
 
 	if (user) {
 		if (!user_mode(regs)) {
-			if  (current->mm)
-				regs = task_pt_regs(current);
-			else
+			if (current->flags & (PF_KTHREAD | PF_USER_WORKER))
 				regs = NULL;
+			else
+				regs = task_pt_regs(current);
 		}
 
 		if (regs) {
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 820127536e62b..ea9ff856770be 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7440,7 +7440,7 @@ static void perf_sample_regs_user(struct perf_regs *regs_user,
 	if (user_mode(regs)) {
 		regs_user->abi = perf_reg_abi(current);
 		regs_user->regs = regs;
-	} else if (!(current->flags & PF_KTHREAD)) {
+	} else if (!(current->flags & (PF_KTHREAD | PF_USER_WORKER))) {
 		perf_get_regs_user(regs_user, regs);
 	} else {
 		regs_user->abi = PERF_SAMPLE_REGS_ABI_NONE;
@@ -8080,7 +8080,7 @@ static u64 perf_virt_to_phys(u64 virt)
 		 * Try IRQ-safe get_user_page_fast_only first.
 		 * If failed, leave phys_addr as 0.
 		 */
-		if (current->mm != NULL) {
+		if (!(current->flags & (PF_KTHREAD | PF_USER_WORKER))) {
 			struct page *p;
 
 			pagefault_disable();
-- 
2.51.0

From: Aaron Lu <ziqianlu@bytedance.com>

[ Upstream commit fcd394866e3db344cbe0bb485d7e3f741ac07245 ]

With task based throttle model, tasks in a throttled hierarchy are
allowed to continue to run if they are running in kernel mode. For this
reason, PELT clock is not stopped for these cfs_rqs in throttled
hierarchy when they still have tasks running or queued.

Since PELT clock is not stopped, whether to allow update_cfs_group()
doing its job for cfs_rqs which are in throttled hierarchy but still
have tasks running/queued is a question.

The good side is, continue to run update_cfs_group() can get these
cfs_rq entities with an up2date weight and that up2date weight can be
useful to derive an accurate load for the CPU as well as ensure fairness
if multiple tasks of different cgroups are running on the same CPU.
OTOH, as Benjamin Segall pointed: when unthrottle comes around the most
likely correct distribution is the distribution we had at the time of
throttle.

In reality, either way may not matter that much if tasks in throttled
hierarchy don't run in kernel mode for too long. But in case that
happens, let these cfs_rq entities have an up2date weight seems a good
thing to do.

Signed-off-by: Aaron Lu <ziqianlu@bytedance.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Backport Status: YES (with critical dependencies)

### Executive Summary

This commit **should be backported** to stable kernel trees, but **only
as part of the complete task-based throttle model series**. In fact,
this commit has **already been backported** to Linux 6.17 stable tree
(commit 4ee521004f8ef) by stable maintainer Sasha Levin, which is strong
evidence of its suitability for stable backporting.

### Code Change Analysis

The commit makes a minimal code change in `kernel/sched/fair.c`,
removing 3 lines from `update_cfs_group()`:

```c
- if (throttled_hierarchy(gcfs_rq))
- return;
-
```

This removal allows `update_cfs_group()` to continue updating group
entity weights even for cgroups in throttled hierarchies. Previously,
line 3960-3961 would cause an early return, preventing weight
recalculation for any throttled cfs_rq.

### Context and Dependencies

**Critical Finding**: This commit is **NOT standalone**. It is part 5 of
a 7-commit series implementing the task-based throttle model:

1. **e1fad12dcb66b** - "Switch to task based throttle model" (341 line
   change - the base)
2. **eb962f251fbba** - "Task based throttle time accounting"
3. **5b726e9bf9544** - "Get rid of throttled_lb_pair()"
4. **fe8d238e646e1** - "Propagate load for throttled cfs_rq"
5. **fcd394866e3db** - "update_cfs_group() for throttled cfs_rqs" ←
   **This commit**
6. **253b3f5872419** - "Do not special case tasks in throttled
   hierarchy" (follow-up fix)
7. **0d4eaf8caf8cd** - "Do not balance task to a throttled cfs_rq"
   (follow-up performance fix)

All 7 commits were backported together to Linux 6.17 stable tree.

### Why This Change Is Necessary

Under the **old throttle model**: When a cfs_rq was throttled, its
entity was dequeued from the CPU's runqueue, preventing all tasks from
running. The PELT clock stopped, so updating group weights was
unnecessary and prevented by the `throttled_hierarchy()` check at line
3960.

Under the **new task-based throttle model** (introduced by commit
e1fad12dcb66b):
- Tasks in throttled hierarchies **continue running if in kernel mode**
- PELT clock **remains active** while throttled tasks still run/queue
- The `throttled_hierarchy()` check at line 3960 becomes **incorrect** -
  it prevents weight updates even though PELT is still running

**The fix**: Remove lines 3960-3961 to allow `calc_group_shares()` (line
3963) and `reweight_entity()` (line 3965) to execute, giving throttled
cfs_rq entities up-to-date weights for accurate CPU load calculation and
cross-cgroup fairness.

### Benefits and Trade-offs

**Benefits** (from commit message):
- Up-to-date weights enable accurate CPU load derivation
- Ensures fairness when multiple tasks from different cgroups run on
  same CPU
- Prevents stale weight values during extended kernel-mode execution

**Trade-offs** (acknowledged in commit):
- As Benjamin Segall noted: "the most likely correct distribution is the
  distribution we had at the time of throttle"
- May not matter much if tasks don't run in kernel mode for long periods
- Performance tuning was needed (see follow-up commit 0d4eaf8caf8cd
  which addresses hackbench regression by preventing load balancing to
  throttled cfs_rqs)

### What Problems Does This Solve?

The base task-based throttle model (e1fad12dcb66b) solves a **real
bug**: With the old model, a task holding a percpu_rwsem as reader in a
throttled cgroup couldn't run until the next period, causing:
- Writers waiting longer
- Reader build-up
- **Task hung warnings**

This specific commit ensures the new model works correctly by keeping
weight calculations accurate during kernel-mode execution of throttled
tasks.

### Risk Assessment

**Low to Medium Risk** for the following reasons:

**Mitigating factors**:
- Small code change (3 lines removed)
- Already backported to 6.17 stable by experienced maintainer
- Well-tested by multiple developers (Valentin Schneider, Chen Yu,
  Matteo Martelli, K Prateek Nayak)
- Part of thoroughly reviewed patch series linked at
  https://lore.kernel.org/r/20250829081120.806-4-ziqianlu@bytedance.com

**Risk factors**:
- Modifies core scheduler behavior in subtle ways
- Requires entire series (cannot be cherry-picked alone)
- Follow-up performance fixes needed (commit 0d4eaf8caf8cd mentions AMD
  Genoa performance degradation with hackbench that required additional
  checks)
- Affects PELT weight calculations during throttling edge cases

**No evidence of**:
- Reverts
- CVE assignments
- Major regression reports
- Security implications

### Backporting Requirements

If backporting to stable trees **without** the task-based throttle
model:

**DO NOT BACKPORT** - This commit will break things. The
`throttled_hierarchy()` check at line 3960 exists for a reason in the
old throttle model where PELT clocks stop on throttle.

If backporting to stable trees **with** the task-based throttle model:

**MUST BACKPORT** as part of the complete series:
1. Base commit e1fad12dcb66b (341 lines - major change)
2. Commits eb962f251fbba, 5b726e9bf9544, fe8d238e646e1
3. **This commit** (fcd394866e3db)
4. **Follow-up fixes** 253b3f5872419 and 0d4eaf8caf8cd

### Stable Tree Rules Compliance

- ✅ **Fixes important bugs**: Yes (task hung due to percpu_rwsem
  interactions)
- ✅ **Relatively small change**: Yes for this commit (3 lines), but
  series is large
- ✅ **Minimal side effects**: When backported with complete series
- ❌ **No major architectural changes**: No - this IS part of a major
  architectural change
- ✅ **Clear benefits**: Yes - prevents task hangs, improves fairness
- ⚠️ **Explicit stable tag**: No "Cc: stable" tag, but manually selected
  by stable maintainer
- ✅ **Minimal regression risk**: When backported with complete series
  and follow-ups

### Recommendation

**YES - Backport this commit**, with the following requirements:

1. **MUST include the entire task-based throttle series** (commits 1-7
   listed above)
2. **MUST include follow-up performance fixes** (especially
   0d4eaf8caf8cd)
3. **Target kernel version**: 6.17+ (already done) or newer LTS versions
   planning major scheduler updates
4. **Not suitable for**: Older stable trees without appetite for the
   341-line base architectural change

The fact that Sasha Levin already backported this entire series to 6.17
stable is the strongest indicator this is appropriate for stable
backporting.

 kernel/sched/fair.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8ce56a8d507f9..eea0b6571af5a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3957,9 +3957,6 @@ static void update_cfs_group(struct sched_entity *se)
 	if (!gcfs_rq || !gcfs_rq->load.weight)
 		return;
 
-	if (throttled_hierarchy(gcfs_rq))
-		return;
-
 	shares = calc_group_shares(gcfs_rq);
 	if (unlikely(se->load.weight != shares))
 		reweight_entity(cfs_rq_of(se), se, shares);
-- 
2.51.0