linux-kernel.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).