sched_tick() only assigns resched_latency when the LATENCY_WARN feature is
enabled, but tests the variable later in a separate feature check.

That leaves the code dependent on both checks observing identical state.
Initializing resched_latency to zero makes the later test safe even if the
feature state changes between the two checks.

This does not change behavior when LATENCY_WARN is enabled. It only avoids
using an uninitialized local value.

Fixes: c006fac556e4 ("sched: Warn on long periods of pending need_resched")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Joseph Salisbury <joseph.salisbury@oracle.com>
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 08a06162dd9a..15916186e4ff 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5548,7 +5548,7 @@ void sched_tick(void)
 	struct task_struct *donor;
 	struct rq_flags rf;
 	unsigned long hw_pressure;
-	u64 resched_latency;
+	u64 resched_latency = 0;
 
 	if (housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE))
 		arch_scale_freq_tick();
-- 
2.47.3

On Tue, 17 Mar 2026 15:58:07 -0400
Joseph Salisbury <joseph.salisbury@oracle.com> wrote:

> sched_tick() only assigns resched_latency when the LATENCY_WARN feature is
> enabled, but tests the variable later in a separate feature check.
> 
> That leaves the code dependent on both checks observing identical state.
> Initializing resched_latency to zero makes the later test safe even if the
> feature state changes between the two checks.
> 
> This does not change behavior when LATENCY_WARN is enabled. It only avoids
> using an uninitialized local value.
> 
> Fixes: c006fac556e4 ("sched: Warn on long periods of pending need_resched")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:GPT-5
> Signed-off-by: Joseph Salisbury <joseph.salisbury@oracle.com>
> ---
>  kernel/sched/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 08a06162dd9a..15916186e4ff 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5548,7 +5548,7 @@ void sched_tick(void)
>  	struct task_struct *donor;
>  	struct rq_flags rf;
>  	unsigned long hw_pressure;
> -	u64 resched_latency;
> +	u64 resched_latency = 0;
>  
>  	if (housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE))
>  		arch_scale_freq_tick();

The code has:

	if (sched_feat(LATENCY_WARN))
		resched_latency = cpu_resched_latency(rq);
	calc_global_load_tick(rq);
	sched_core_tick(rq);
	scx_tick(rq);

	rq_unlock(rq, &rf);

	if (sched_feat(LATENCY_WARN) && resched_latency)
		resched_latency_warn(cpu, resched_latency);


I guess if LATENCY_WARN gets enabled between the first check and the
second, then the resched_latency could be uninitialized.

Heck, probably could even get rid of the second sched_feat(LATENCY_WARN),
and make it simply:

	if (resched_latency)

Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>

-- Steve

Hi.

> 
> The code has:
> 
> 	if (sched_feat(LATENCY_WARN))
> 		resched_latency = cpu_resched_latency(rq);
> 	calc_global_load_tick(rq);
> 	sched_core_tick(rq);
> 	scx_tick(rq);
> 
> 	rq_unlock(rq, &rf);
> 
> 	if (sched_feat(LATENCY_WARN) && resched_latency)
> 		resched_latency_warn(cpu, resched_latency);
> 
> 
> I guess if LATENCY_WARN gets enabled between the first check and the
> second, then the resched_latency could be uninitialized.
> 
> Heck, probably could even get rid of the second sched_feat(LATENCY_WARN),
> and make it simply:
> 
> 	if (resched_latency)
> 
> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> 
> -- Steve

Whats the relevance of resched_latency warnings in the age of preempt
kernels being the default for majority of the archs.

In case of full/lazy preemption, at the end of sched_tick itself we would call
schedule if need_resched is set provided it was preemptible.

It kind of makes sense for non preemptive kernels. But we have preemptoff and
preemptirqoff tracers which one could use. (although may need a kernel build)

What bugs is it catching these days?

On Wed, 18 Mar 2026 12:00:58 +0530
Shrikanth Hegde <sshegde@linux.ibm.com> wrote:

> Whats the relevance of resched_latency warnings in the age of preempt
> kernels being the default for majority of the archs.
> 
> In case of full/lazy preemption, at the end of sched_tick itself we would call
> schedule if need_resched is set provided it was preemptible.
> 
> It kind of makes sense for non preemptive kernels. But we have preemptoff and
> preemptirqoff tracers which one could use. (although may need a kernel build)
> 
> What bugs is it catching these days?

Good point. I've never used it. I guess the question is, does anyone?

-- Steve

On Wed, Mar 18, 2026 at 10:48:26AM -0400, Steven Rostedt wrote:
> On Wed, 18 Mar 2026 12:00:58 +0530
> Shrikanth Hegde <sshegde@linux.ibm.com> wrote:
> 
> > Whats the relevance of resched_latency warnings in the age of preempt
> > kernels being the default for majority of the archs.
> > 
> > In case of full/lazy preemption, at the end of sched_tick itself we would call
> > schedule if need_resched is set provided it was preemptible.
> > 
> > It kind of makes sense for non preemptive kernels. But we have preemptoff and
> > preemptirqoff tracers which one could use. (although may need a kernel build)
> > 
> > What bugs is it catching these days?
> 
> Good point. I've never used it. I guess the question is, does anyone?

Google added that, Ben are you guys still needing that?