From: Frederic Weisbecker <fweisbec@gmail.com>
To: Don Zickus <dzickus@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
akpm@linux-foundation.org, sergey.senozhatsky@gmail.com
Subject: Re: [PATCH] watchdog: touch_nmi_watchdog should only touch local cpu not every one
Date: Sun, 7 Nov 2010 23:09:11 +0100 [thread overview]
Message-ID: <20101107220909.GF11134@nowhere> (raw)
In-Reply-To: <1288919932-1857-1-git-send-email-dzickus@redhat.com>
On Thu, Nov 04, 2010 at 09:18:52PM -0400, Don Zickus wrote:
> I ran into a scenario where while one cpu was stuck and should have panic'd
> because of the NMI watchdog, it didn't. The reason was another cpu was spewing
> stack dumps on to the console. Upon investigation, I noticed that when writing
> to the console and also when dumping the stack, the watchdog is touched.
>
> This causes all the cpus to reset their NMI watchdog flags and the 'stuck' cpu
> just spins forever.
>
> This change causes the semantics of touch_nmi_watchdog to be changed slightly.
> Previously, I accidentally changed the semantics and we noticed there was a
> codepath in which touch_nmi_watchdog could be touched from a preemtible area.
> That caused a BUG() to happen when CONFIG_DEBUG_PREEMPT was enabled. I believe
> it was the acpi code.
>
> My attempt here re-introduces the change to have the touch_nmi_watchdog() code
> only touch the local cpu instead of all of the cpus. But instead of using
> __get_cpu_var(), I use the __raw_get_cpu_var() version.
>
> This avoids the preemption problem. However my reasoning wasn't because I was
> trying to be lazy. Instead I rationalized it as, well if preemption is enabled
> then interrupts should be enabled to and the NMI watchdog will have no reason
> to trigger. So it won't matter if the wrong cpu is touched because the percpu
> interrupt counters the NMI watchdog uses should still be incrementing.
>
> Signed-off-by: Don Zickus <dzickus@redhat.com>
> ---
> kernel/watchdog.c | 17 ++++++++++++++++-
> 1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> index dc8e168..dd0c140 100644
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@ -141,6 +141,21 @@ void touch_all_softlockup_watchdogs(void)
> #ifdef CONFIG_HARDLOCKUP_DETECTOR
> void touch_nmi_watchdog(void)
> {
> + /*
> + * Using __raw here because some code paths have
> + * preemption enabled. If preemption is enabled
> + * then interrupts should be enabled too, in which
> + * case we shouldn't have to worry about the watchdog
> + * going off.
> + */
> + __raw_get_cpu_var(watchdog_nmi_touch) = true;
> +
> + touch_softlockup_watchdog();
> +}
> +EXPORT_SYMBOL(touch_nmi_watchdog);
Did the old watchdog also touched every CPUs?
That doesn't appear to be a good thing, we may indeed miss hardlockups
because of that.
And it seems you can drop touch_all_nmi_watchdogs() as, like others
pointed out, there are no users of it.
next prev parent reply other threads:[~2010-11-07 22:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 1:18 [PATCH] watchdog: touch_nmi_watchdog should only touch local cpu not every one Don Zickus
2010-11-05 13:51 ` Sergey Senozhatsky
2010-11-05 19:58 ` Andrew Morton
2010-11-08 13:37 ` Don Zickus
2010-11-07 22:09 ` Frederic Weisbecker [this message]
2010-11-08 13:38 ` Don Zickus
-- strict thread matches above, loose matches on Subject: below --
2013-12-05 3:12 [PATCH v2] watchdog: Add a sysctl to disable soft lockup detector Don Zickus
2013-12-05 20:42 ` [PATCH] watchdog: touch_nmi_watchdog should only touch local cpu not every one Ben Zhang
2013-12-16 15:55 ` Don Zickus
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=20101107220909.GF11134@nowhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dzickus@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sergey.senozhatsky@gmail.com \
/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.