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
>
next prev parent 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).