[patch 1/2] sched/debug: Change need_resched warnings to pr_err

[patch 1/2] sched/debug: Change need_resched warnings to pr_err

[David Rientjes]

need_resched warnings, if enabled, are treated as WARNINGs.  If
kernel.panic_on_warn is enabled, then this causes a kernel panic.

It's highly unlikely that a panic is desired for these warnings, only a
stack trace is normally required to debug and resolve.

Thus, switch need_resched warnings to simply be a printk with an
associated stack trace so they are no longer in scope for panic_on_warn.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 kernel/sched/debug.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -1295,8 +1295,10 @@ void resched_latency_warn(int cpu, u64 latency)
 {
 	static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
 
-	WARN(__ratelimit(&latency_check_ratelimit),
-	     "sched: CPU %d need_resched set for > %llu ns (%d ticks) "
-	     "without schedule\n",
-	     cpu, latency, cpu_rq(cpu)->ticks_without_resched);
+	if (likely(!__ratelimit(&latency_check_ratelimit)))
+		return;
+
+	pr_err("sched: CPU %d need_resched set for > %llu ns (%d ticks) without schedule\n",
+	       cpu, latency, cpu_rq(cpu)->ticks_without_resched);
+	dump_stack();
 }

Re: [patch 1/2] sched/debug: Change need_resched warnings to pr_err

[Josh Don]

On Mon, Jan 6, 2025 at 12:39 PM David Rientjes <rientjes@google.com> wrote:
>
> need_resched warnings, if enabled, are treated as WARNINGs.  If
> kernel.panic_on_warn is enabled, then this causes a kernel panic.
>
> It's highly unlikely that a panic is desired for these warnings, only a
> stack trace is normally required to debug and resolve.
>
> Thus, switch need_resched warnings to simply be a printk with an
> associated stack trace so they are no longer in scope for panic_on_warn.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  kernel/sched/debug.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -1295,8 +1295,10 @@ void resched_latency_warn(int cpu, u64 latency)
>  {
>         static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
>
> -       WARN(__ratelimit(&latency_check_ratelimit),
> -            "sched: CPU %d need_resched set for > %llu ns (%d ticks) "
> -            "without schedule\n",
> -            cpu, latency, cpu_rq(cpu)->ticks_without_resched);
> +       if (likely(!__ratelimit(&latency_check_ratelimit)))
> +               return;
> +
> +       pr_err("sched: CPU %d need_resched set for > %llu ns (%d ticks) without schedule\n",
> +              cpu, latency, cpu_rq(cpu)->ticks_without_resched);
> +       dump_stack();
>  }
>

Thanks David, looks reasonable to me.

Acked-by: Josh Don <joshdon@google.com>

Re: [patch 1/2] sched/debug: Change need_resched warnings to pr_err

[Madadi Vineeth Reddy]

Hi David Rientjes,

On 07/01/25 02:09, David Rientjes wrote:
> need_resched warnings, if enabled, are treated as WARNINGs.  If
> kernel.panic_on_warn is enabled, then this causes a kernel panic.
> 
> It's highly unlikely that a panic is desired for these warnings, only a
> stack trace is normally required to debug and resolve.
> 
> Thus, switch need_resched warnings to simply be a printk with an
> associated stack trace so they are no longer in scope for panic_on_warn.
> 
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  kernel/sched/debug.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -1295,8 +1295,10 @@ void resched_latency_warn(int cpu, u64 latency)
>  {
>  	static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
>  
> -	WARN(__ratelimit(&latency_check_ratelimit),
> -	     "sched: CPU %d need_resched set for > %llu ns (%d ticks) "
> -	     "without schedule\n",
> -	     cpu, latency, cpu_rq(cpu)->ticks_without_resched);
> +	if (likely(!__ratelimit(&latency_check_ratelimit)))
> +		return;
> +
> +	pr_err("sched: CPU %d need_resched set for > %llu ns (%d ticks) without schedule\n",
> +	       cpu, latency, cpu_rq(cpu)->ticks_without_resched);

LGTM. While this is an issue, it doesn't necessarily indicate a critical failure that would
require the kernel to panic.

Nit: Would using pr_warn instead be too lenient in this case?

Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>

Thanks,
Madadi Vineeth Reddy

> +	dump_stack();
>  }

Re: [patch 1/2] sched/debug: Change need_resched warnings to pr_err

[David Rientjes]

On Wed, 8 Jan 2025, Madadi Vineeth Reddy wrote:

> Hi David Rientjes,
> 
> On 07/01/25 02:09, David Rientjes wrote:
> > need_resched warnings, if enabled, are treated as WARNINGs.  If
> > kernel.panic_on_warn is enabled, then this causes a kernel panic.
> > 
> > It's highly unlikely that a panic is desired for these warnings, only a
> > stack trace is normally required to debug and resolve.
> > 
> > Thus, switch need_resched warnings to simply be a printk with an
> > associated stack trace so they are no longer in scope for panic_on_warn.
> > 
> > Signed-off-by: David Rientjes <rientjes@google.com>
> > ---
> >  kernel/sched/debug.c | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> > --- a/kernel/sched/debug.c
> > +++ b/kernel/sched/debug.c
> > @@ -1295,8 +1295,10 @@ void resched_latency_warn(int cpu, u64 latency)
> >  {
> >  	static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
> >  
> > -	WARN(__ratelimit(&latency_check_ratelimit),
> > -	     "sched: CPU %d need_resched set for > %llu ns (%d ticks) "
> > -	     "without schedule\n",
> > -	     cpu, latency, cpu_rq(cpu)->ticks_without_resched);
> > +	if (likely(!__ratelimit(&latency_check_ratelimit)))
> > +		return;
> > +
> > +	pr_err("sched: CPU %d need_resched set for > %llu ns (%d ticks) without schedule\n",
> > +	       cpu, latency, cpu_rq(cpu)->ticks_without_resched);
> 
> LGTM. While this is an issue, it doesn't necessarily indicate a critical failure that would
> require the kernel to panic.
> 
> Nit: Would using pr_warn instead be too lenient in this case?
> 

Thanks!  I pondered the log level here for about five seconds, I'm 
indifferent to pr_err() or pr_warn() :)  Since the stack trace is the most 
critical element of the output here, imo, and it has its own log level, I 
didn't feel strongly for either err or warn.

> Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
> 
> Thanks,
> Madadi Vineeth Reddy
> 
> > +	dump_stack();
> >  }
> 
> 

[patch v2] sched/debug: Change need_resched warnings to pr_err

[David Rientjes]

need_resched warnings, if enabled, are treated as WARNINGs.  If
kernel.panic_on_warn is enabled, then this causes a kernel panic.

It's highly unlikely that a panic is desired for these warnings, only a
stack trace is normally required to debug and resolve.

Thus, switch need_resched warnings to simply be a printk with an
associated stack trace so they are no longer in scope for panic_on_warn.

Acked-by: Josh Don <joshdon@google.com>
Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Signed-off-by: David Rientjes <rientjes@google.com>
---
 v2: added Acked-by and Reviewed-by, dropped second patch in the series

 kernel/sched/debug.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -1295,8 +1295,10 @@ void resched_latency_warn(int cpu, u64 latency)
 {
 	static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
 
-	WARN(__ratelimit(&latency_check_ratelimit),
-	     "sched: CPU %d need_resched set for > %llu ns (%d ticks) "
-	     "without schedule\n",
-	     cpu, latency, cpu_rq(cpu)->ticks_without_resched);
+	if (likely(!__ratelimit(&latency_check_ratelimit)))
+		return;
+
+	pr_err("sched: CPU %d need_resched set for > %llu ns (%d ticks) without schedule\n",
+	       cpu, latency, cpu_rq(cpu)->ticks_without_resched);
+	dump_stack();
 }

[tip: sched/core] sched/debug: Change need_resched warnings to pr_err

[tip-bot2 for David Rientjes]

The following commit has been merged into the sched/core branch of tip:

Commit-ID:     8061b9f5e111a3012f8b691e5b75dd81eafbb793
Gitweb:        https://git.kernel.org/tip/8061b9f5e111a3012f8b691e5b75dd81eafbb793
Author:        David Rientjes <rientjes@google.com>
AuthorDate:    Thu, 09 Jan 2025 16:24:33 -08:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Mon, 13 Jan 2025 14:10:23 +01:00

sched/debug: Change need_resched warnings to pr_err

need_resched warnings, if enabled, are treated as WARNINGs.  If
kernel.panic_on_warn is enabled, then this causes a kernel panic.

It's highly unlikely that a panic is desired for these warnings, only a
stack trace is normally required to debug and resolve.

Thus, switch need_resched warnings to simply be a printk with an
associated stack trace so they are no longer in scope for panic_on_warn.

Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Acked-by: Josh Don <joshdon@google.com>
Link: https://lkml.kernel.org/r/e8d52023-5291-26bd-5299-8bb9eb604929@google.com
---
 kernel/sched/debug.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 5e8e84a..fd7e852 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -1292,8 +1292,10 @@ void resched_latency_warn(int cpu, u64 latency)
 {
 	static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
 
-	WARN(__ratelimit(&latency_check_ratelimit),
-	     "sched: CPU %d need_resched set for > %llu ns (%d ticks) "
-	     "without schedule\n",
-	     cpu, latency, cpu_rq(cpu)->ticks_without_resched);
+	if (likely(!__ratelimit(&latency_check_ratelimit)))
+		return;
+
+	pr_err("sched: CPU %d need_resched set for > %llu ns (%d ticks) without schedule\n",
+	       cpu, latency, cpu_rq(cpu)->ticks_without_resched);
+	dump_stack();
 }