All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	"Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
Subject: Re: [RFC PATCH 2/2] sched: sysctl: Panic on scheduling while atomic
Date: Tue, 31 May 2016 12:20:04 -0700	[thread overview]
Message-ID: <20160531192004.GB4574@x> (raw)
In-Reply-To: <654ac2ba100f609917b68d1c6a33331ec9df8da4.1464652607.git.bristot@redhat.com>

On Tue, May 31, 2016 at 04:07:33PM -0300, Daniel Bristot de Oliveira wrote:
> Currently, a schedule while atomic error prints the stack trace to the
> kernel log and the system continue running.
> 
> Although it is possible to collect the kernel log messages and analyse
> it, often more information are needed. Furthermore, keep the system
> running is not always the best choice. For example, when the preempt
> count underflows the system will not stop to complain about scheduling
> while atomic, so the kernel log can wraparound overwriting the first
> stack trace, tuning the analysis even more difficult.
> 
> This patch implements the kernel.panic_on_sched_in_atomic sysctl to
> help out on these more complex situations.
> 
> When kernel.panic_on_sched_in_atomic is set to 1, the kernel will
> panic() in the schedule while atomic detection.
> 
> The default value for the sysctl is 0, maintaining the current behavior.
> 
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Reviewed-by: Arnaldo Carvalho de Melo <acme@kernel.org>
> Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>

Reviewed-by: Josh Triplett <josh@joshtriplett.org>

>  Documentation/sysctl/kernel.txt | 13 +++++++++++++
>  include/linux/kernel.h          |  1 +
>  kernel/sched/core.c             |  7 +++++++
>  kernel/sysctl.c                 |  9 +++++++++
>  4 files changed, 30 insertions(+)
> 
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 29ec4bb..0b176bb 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -59,6 +59,7 @@ show up in /proc/sys/kernel:
>  - panic_on_unrecovered_nmi
>  - panic_on_warn
>  - panic_on_rcu_stall
> +- panic_on_sched_in_atomic
>  - perf_cpu_time_max_percent
>  - perf_event_paranoid
>  - perf_event_max_stack
> @@ -630,6 +631,18 @@ is useful to define the root cause of RCU stalls using kdump.
>  
>  ==============================================================
>  
> +panic_on_sched_in_atomic:
> +
> +When set to 1, calls panic() in the schedule while in atomic detection.
> +This is useful get a vmcore to inspect the root cause of a schedule()
> +call in the atomic context.
> +
> +0: do not panic() on scheduling while in atomic, default behavior.
> +
> +1: panic() after printing schedule while in atomic messages.
> +
> +==============================================================
> +
>  perf_cpu_time_max_percent:
>  
>  Hints to the kernel how much CPU time it should be allowed to
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index c420821..e4d9804 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -452,6 +452,7 @@ extern int panic_on_unrecovered_nmi;
>  extern int panic_on_io_nmi;
>  extern int panic_on_warn;
>  extern int sysctl_panic_on_rcu_stall;
> +extern int sysctl_panic_on_sched_in_atomic;
>  extern int sysctl_panic_on_stackoverflow;
>  
>  extern bool crash_kexec_post_notifiers;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7f2cae4..602f978 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -152,6 +152,11 @@ __read_mostly int scheduler_running;
>   */
>  int sysctl_sched_rt_runtime = 950000;
>  
> +/*
> + * panic on scheduling while atomic
> + */
> +__read_mostly int sysctl_panic_on_sched_in_atomic = 0;
> +
>  /* cpus with isolated domains */
>  cpumask_var_t cpu_isolated_map;
>  
> @@ -3146,6 +3151,8 @@ static noinline void __schedule_bug(struct task_struct *prev)
>  		pr_cont("\n");
>  	}
>  #endif
> +	if (sysctl_panic_on_sched_in_atomic)
> +		panic("scheduling while atomic\n");
>  	dump_stack();
>  	add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
>  }
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index d3b93aa..f0a984c 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1216,6 +1216,15 @@ static struct ctl_table kern_table[] = {
>  		.extra2		= &one,
>  	},
>  #endif
> +	{
> +		.procname	= "panic_on_sched_in_atomic",
> +		.data		= &sysctl_panic_on_sched_in_atomic,
> +		.maxlen		= sizeof(sysctl_panic_on_sched_in_atomic),
> +		.mode		= 0644,
> +		.proc_handler	= proc_dointvec_minmax,
> +		.extra1		= &zero,
> +		.extra2		= &one,
> +	},
>  	{ }
>  };
>  
> -- 
> 2.5.5
> 

  reply	other threads:[~2016-05-31 19:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 19:07 [RFC PATCH 0/2] sysctl: Panic on RCU stall and schedule while atomic Daniel Bristot de Oliveira
2016-05-31 19:07 ` [RFC PATCH 1/2] rcu: sysctl: Panic on RCU Stall Daniel Bristot de Oliveira
2016-05-31 19:18   ` Josh Triplett
2016-05-31 19:23     ` Josh Triplett
2016-05-31 22:49       ` Daniel Bristot de Oliveira
2016-06-01  2:34         ` Paul E. McKenney
2016-05-31 19:07 ` [RFC PATCH 2/2] sched: sysctl: Panic on scheduling while atomic Daniel Bristot de Oliveira
2016-05-31 19:20   ` Josh Triplett [this message]
2016-06-01  9:45   ` Peter Zijlstra
2016-06-01 13:37     ` Daniel Bristot de Oliveira
2016-05-31 19:27 ` [RFC PATCH 0/2] sysctl: Panic on RCU stall and schedule " Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160531192004.GB4574@x \
    --to=josh@joshtriplett.org \
    --cc=acme@kernel.org \
    --cc=bristot@redhat.com \
    --cc=corbet@lwn.net \
    --cc=jiangshanlai@gmail.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.