From: Peter Zijlstra <peterz@infradead.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
Date: Tue, 30 Oct 2018 08:25:25 +0000 [thread overview]
Message-ID: <20181030082525.GA13436@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181029180707.207546-7-dianders@chromium.org>
On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote:
> In kgdb_roundup_cpus() we've got code that looks like:
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> local_irq_disable();
> Let's add kgdb to the list of reasons not to warn in
> smp_call_function_many(). That will allow us (in a future patch) to
> stop calling local_irq_enable() which will get rid of the original
> splat.
>
> NOTE: with this change comes the obvious question: will we start
> deadlocking more often now when we drop into the debugger. I can't
> say that for sure one way or the other, but the fact that we do the
> same logic for "oops_in_progress" makes me feel like it shouldn't
> happen too often. Also note that the old logic of turning on
> interrupts temporarily wasn't exactly safe since (I presume) that
> could have violated spin_lock_irqsave() semantics and ended up with a
> deadlock of its own.
How is any of that not utterly and terminally broken?
> @@ -413,7 +414,8 @@ void smp_call_function_many(const struct cpumask *mask,
> * can't happen.
> */
> WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> - && !oops_in_progress && !early_boot_irqs_disabled);
> + && !oops_in_progress && !early_boot_irqs_disabled
> + && !in_dbg_master());
>
> /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */
> cpu = cpumask_first_and(mask, cpu_online_mask);
Not a fan of this. There is a distinct difference between
oops_in_progress and dropping into kgdb in that you don't ever expect to
return/survive oopses, whereas we do expect to survive kgdb.
Also, how does kgdb work at all without actual NMIs ?
So no, NAK on this.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: Jason Wessel <jason.wessel@windriver.com>,
Daniel Thompson <daniel.thompson@linaro.org>,
tglx@linutronix.de, mingo@kernel.org, gregkh@linuxfoundation.org,
linux-arm-msm@vger.kernel.org,
kgdb-bugreport@lists.sourceforge.net, linux-mips@linux-mips.org,
linux-sh@vger.kernel.org, linux-hexagon@vger.kernel.org,
frederic@kernel.org, riel@surriel.com,
linux-kernel@vger.kernel.org, luto@kernel.org,
sparclinux@vger.kernel.org, linux-snps-arc@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
Date: Tue, 30 Oct 2018 09:25:25 +0100 [thread overview]
Message-ID: <20181030082525.GA13436@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181029180707.207546-7-dianders@chromium.org>
On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote:
> In kgdb_roundup_cpus() we've got code that looks like:
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> local_irq_disable();
> Let's add kgdb to the list of reasons not to warn in
> smp_call_function_many(). That will allow us (in a future patch) to
> stop calling local_irq_enable() which will get rid of the original
> splat.
>
> NOTE: with this change comes the obvious question: will we start
> deadlocking more often now when we drop into the debugger. I can't
> say that for sure one way or the other, but the fact that we do the
> same logic for "oops_in_progress" makes me feel like it shouldn't
> happen too often. Also note that the old logic of turning on
> interrupts temporarily wasn't exactly safe since (I presume) that
> could have violated spin_lock_irqsave() semantics and ended up with a
> deadlock of its own.
How is any of that not utterly and terminally broken?
> @@ -413,7 +414,8 @@ void smp_call_function_many(const struct cpumask *mask,
> * can't happen.
> */
> WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> - && !oops_in_progress && !early_boot_irqs_disabled);
> + && !oops_in_progress && !early_boot_irqs_disabled
> + && !in_dbg_master());
>
> /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */
> cpu = cpumask_first_and(mask, cpu_online_mask);
Not a fan of this. There is a distinct difference between
oops_in_progress and dropping into kgdb in that you don't ever expect to
return/survive oopses, whereas we do expect to survive kgdb.
Also, how does kgdb work at all without actual NMIs ?
So no, NAK on this.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: linux-mips@linux-mips.org,
Daniel Thompson <daniel.thompson@linaro.org>,
linux-sh@vger.kernel.org, gregkh@linuxfoundation.org,
frederic@kernel.org, Jason Wessel <jason.wessel@windriver.com>,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, luto@kernel.org,
linux-arm-msm@vger.kernel.org,
kgdb-bugreport@lists.sourceforge.net,
linux-hexagon@vger.kernel.org, tglx@linutronix.de,
linux-snps-arc@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, mingo@kernel.org,
riel@surriel.com
Subject: Re: [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
Date: Tue, 30 Oct 2018 09:25:25 +0100 [thread overview]
Message-ID: <20181030082525.GA13436@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181029180707.207546-7-dianders@chromium.org>
On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote:
> In kgdb_roundup_cpus() we've got code that looks like:
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> local_irq_disable();
> Let's add kgdb to the list of reasons not to warn in
> smp_call_function_many(). That will allow us (in a future patch) to
> stop calling local_irq_enable() which will get rid of the original
> splat.
>
> NOTE: with this change comes the obvious question: will we start
> deadlocking more often now when we drop into the debugger. I can't
> say that for sure one way or the other, but the fact that we do the
> same logic for "oops_in_progress" makes me feel like it shouldn't
> happen too often. Also note that the old logic of turning on
> interrupts temporarily wasn't exactly safe since (I presume) that
> could have violated spin_lock_irqsave() semantics and ended up with a
> deadlock of its own.
How is any of that not utterly and terminally broken?
> @@ -413,7 +414,8 @@ void smp_call_function_many(const struct cpumask *mask,
> * can't happen.
> */
> WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> - && !oops_in_progress && !early_boot_irqs_disabled);
> + && !oops_in_progress && !early_boot_irqs_disabled
> + && !in_dbg_master());
>
> /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */
> cpu = cpumask_first_and(mask, cpu_online_mask);
Not a fan of this. There is a distinct difference between
oops_in_progress and dropping into kgdb in that you don't ever expect to
return/survive oopses, whereas we do expect to survive kgdb.
Also, how does kgdb work at all without actual NMIs ?
So no, NAK on this.
WARNING: multiple messages have this Message-ID (diff)
From: peterz@infradead.org (Peter Zijlstra)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
Date: Tue, 30 Oct 2018 09:25:25 +0100 [thread overview]
Message-ID: <20181030082525.GA13436@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181029180707.207546-7-dianders@chromium.org>
On Mon, Oct 29, 2018@11:07:06AM -0700, Douglas Anderson wrote:
> In kgdb_roundup_cpus() we've got code that looks like:
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> local_irq_disable();
> Let's add kgdb to the list of reasons not to warn in
> smp_call_function_many(). That will allow us (in a future patch) to
> stop calling local_irq_enable() which will get rid of the original
> splat.
>
> NOTE: with this change comes the obvious question: will we start
> deadlocking more often now when we drop into the debugger. I can't
> say that for sure one way or the other, but the fact that we do the
> same logic for "oops_in_progress" makes me feel like it shouldn't
> happen too often. Also note that the old logic of turning on
> interrupts temporarily wasn't exactly safe since (I presume) that
> could have violated spin_lock_irqsave() semantics and ended up with a
> deadlock of its own.
How is any of that not utterly and terminally broken?
> @@ -413,7 +414,8 @@ void smp_call_function_many(const struct cpumask *mask,
> * can't happen.
> */
> WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> - && !oops_in_progress && !early_boot_irqs_disabled);
> + && !oops_in_progress && !early_boot_irqs_disabled
> + && !in_dbg_master());
>
> /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */
> cpu = cpumask_first_and(mask, cpu_online_mask);
Not a fan of this. There is a distinct difference between
oops_in_progress and dropping into kgdb in that you don't ever expect to
return/survive oopses, whereas we do expect to survive kgdb.
Also, how does kgdb work at all without actual NMIs ?
So no, NAK on this.
WARNING: multiple messages have this Message-ID (diff)
From: peterz@infradead.org (Peter Zijlstra)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
Date: Tue, 30 Oct 2018 09:25:25 +0100 [thread overview]
Message-ID: <20181030082525.GA13436@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181029180707.207546-7-dianders@chromium.org>
On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote:
> In kgdb_roundup_cpus() we've got code that looks like:
> local_irq_enable();
> smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> local_irq_disable();
> Let's add kgdb to the list of reasons not to warn in
> smp_call_function_many(). That will allow us (in a future patch) to
> stop calling local_irq_enable() which will get rid of the original
> splat.
>
> NOTE: with this change comes the obvious question: will we start
> deadlocking more often now when we drop into the debugger. I can't
> say that for sure one way or the other, but the fact that we do the
> same logic for "oops_in_progress" makes me feel like it shouldn't
> happen too often. Also note that the old logic of turning on
> interrupts temporarily wasn't exactly safe since (I presume) that
> could have violated spin_lock_irqsave() semantics and ended up with a
> deadlock of its own.
How is any of that not utterly and terminally broken?
> @@ -413,7 +414,8 @@ void smp_call_function_many(const struct cpumask *mask,
> * can't happen.
> */
> WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> - && !oops_in_progress && !early_boot_irqs_disabled);
> + && !oops_in_progress && !early_boot_irqs_disabled
> + && !in_dbg_master());
>
> /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */
> cpu = cpumask_first_and(mask, cpu_online_mask);
Not a fan of this. There is a distinct difference between
oops_in_progress and dropping into kgdb in that you don't ever expect to
return/survive oopses, whereas we do expect to survive kgdb.
Also, how does kgdb work at all without actual NMIs ?
So no, NAK on this.
next prev parent reply other threads:[~2018-10-30 8:25 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 18:07 [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` [PATCH 1/7] serial: qcom_geni_serial: Finish supporting sysrq Douglas Anderson
2018-11-02 16:47 ` Stephen Boyd
2018-11-02 16:47 ` Stephen Boyd
2018-10-29 18:07 ` [PATCH 2/7] serial: core: Allow processing sysrq at port unlock time Douglas Anderson
2018-10-30 5:31 ` Doug Anderson
2018-10-29 18:07 ` [PATCH 3/7] serial: qcom_geni_serial: Process " Douglas Anderson
2018-10-29 18:07 ` [PATCH 4/7] serial: core: Include console.h from serial_core.h Douglas Anderson
2018-10-29 18:07 ` [PATCH 5/7] serial: 8250: Process sysrq at port unlock time Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus() Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-30 8:25 ` Peter Zijlstra [this message]
2018-10-30 8:25 ` Peter Zijlstra
2018-10-30 8:25 ` Peter Zijlstra
2018-10-30 8:25 ` Peter Zijlstra
2018-10-30 8:25 ` Peter Zijlstra
2018-10-30 9:41 ` Daniel Thompson
2018-10-30 9:41 ` Daniel Thompson
2018-10-30 9:41 ` Daniel Thompson
2018-10-30 9:41 ` Daniel Thompson
2018-10-30 9:41 ` Daniel Thompson
2018-10-30 22:21 ` Doug Anderson
2018-10-30 22:21 ` Doug Anderson
2018-10-30 22:21 ` Doug Anderson
2018-10-30 22:21 ` Doug Anderson
2018-10-30 22:21 ` Doug Anderson
2018-10-29 18:07 ` [PATCH 7/7] kgdb: Remove irq flags and local_irq_enable/disable from roundup Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-29 18:07 ` Douglas Anderson
2018-10-30 11:46 ` Daniel Thompson
2018-10-30 11:46 ` Daniel Thompson
2018-10-30 11:46 ` Daniel Thompson
2018-10-30 11:46 ` Daniel Thompson
2018-10-30 11:46 ` Daniel Thompson
2018-10-30 11:46 ` Daniel Thompson
2018-10-30 22:22 ` Doug Anderson
2018-10-30 22:22 ` Doug Anderson
2018-10-30 22:22 ` Doug Anderson
2018-10-30 22:22 ` Doug Anderson
2018-10-30 22:22 ` Doug Anderson
2018-10-30 22:22 ` Doug Anderson
2018-10-30 11:56 ` [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb Daniel Thompson
2018-10-30 11:56 ` Daniel Thompson
2018-10-30 11:56 ` Daniel Thompson
2018-10-30 11:56 ` Daniel Thompson
2018-10-30 12:31 ` Russell King - ARM Linux
2018-10-30 12:31 ` Russell King - ARM Linux
2018-10-30 12:31 ` Russell King - ARM Linux
2018-10-30 12:31 ` Russell King - ARM Linux
2018-10-30 22:20 ` Doug Anderson
2018-10-30 22:20 ` Doug Anderson
2018-10-30 22:20 ` Doug Anderson
2018-10-30 22:20 ` Doug Anderson
2018-10-30 12:36 ` Andy Shevchenko
2018-10-30 12:36 ` Andy Shevchenko
2018-10-30 12:36 ` Andy Shevchenko
2018-10-30 12:36 ` Andy Shevchenko
2018-10-30 12:36 ` Andy Shevchenko
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=20181030082525.GA13436@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-arm-kernel@lists.infradead.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.