All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Thomas Gleixner <tglx@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
	suresh.b.siddha@intel.com, santosh.shilimkar@ti.com,
	tglx@linutronix.de
Subject: [tip:timers/urgent] tick: Ensure that the broadcast device is initialized
Date: Thu, 19 Apr 2012 12:37:49 -0700	[thread overview]
Message-ID: <tip-b9a6a23566960d0dd3f51e2e68b472cd61911078@git.kernel.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1204181723350.2542@ionos>

Commit-ID:  b9a6a23566960d0dd3f51e2e68b472cd61911078
Gitweb:     http://git.kernel.org/tip/b9a6a23566960d0dd3f51e2e68b472cd61911078
Author:     Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Wed, 18 Apr 2012 17:31:58 +0200
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Thu, 19 Apr 2012 21:27:35 +0200

tick: Ensure that the broadcast device is initialized

Santosh found another trap when we avoid to initialize the broadcast
device in the switch_to_oneshot code. The broadcast device might be
still in SHUTDOWN state when we actually need to use it. That
obviously breaks, as set_next_event() is called on a shutdown
device. This did not break on x86, but Suresh analyzed it:

>From the review, most likely on Sven's system we are force enabling
the hpet using the pci quirk's method very late. And in this case,
hpet_clockevent (which will be global_clock_event) handler can be
null, specifically as this platform might not be using deeper c-states
and using the reliable APIC timer.

Prior to commit 'fa4da365bc7772c', that handler will be set to
'tick_handle_oneshot_broadcast' when we switch the broadcast timer to
oneshot mode, even though we don't use it. Post commit
'fa4da365bc7772c', we stopped switching the broadcast mode to oneshot
as this is not really needed and his platform's global_clock_event's
handler will remain null. While on my SNB laptop, same is set to
'clockevents_handle_noop' because hpet gets enabled very early. (noop
handler on my platform set when the early enabled hpet timer gets
replaced by the lapic timer).

But the commit 'fa4da365bc7772c' tracked the broadcast timer mode in
the SW as oneshot, even though it didn't touch the HW timer. During
resume however, tick_resume_broadcast() saw the SW broadcast mode as
oneshot and actually programmed the broadcast device also into oneshot
mode. So this triggered the null pointer de-reference after the hpet
wraps around and depending on what the hpet counter is set to. On the
normal platforms where hpet gets enabled early we should be seeing a
spurious interrupt (in my SNB laptop I see one spurious interrupt
after around 5 minutes ;) which is 32-bit hpet counter wraparound
time), but that's a separate issue.

Enforce the mode setting when trying to set an event.

Reported-and-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: torvalds@linux-foundation.org
Cc: svenjoac@gmx.de
Cc: rjw@sisk.pl
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1204181723350.2542@ionos

---
 kernel/time/tick-broadcast.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 119aca5..029531f 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -373,6 +373,9 @@ static int tick_broadcast_set_event(ktime_t expires, int force)
 {
 	struct clock_event_device *bc = tick_broadcast_device.evtdev;
 
+	if (bc->mode != CLOCK_EVT_MODE_ONESHOT)
+		clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
+
 	return clockevents_program_event(bc, expires, force);
 }
 

      parent reply	other threads:[~2012-04-19 19:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-16  1:49 Linux 3.4-rc3 Linus Torvalds
2012-04-17 15:24 ` kernel panic after suspend/resume (was: Linux 3.4-rc3) Sven Joachim
2012-04-17 16:00   ` Linus Torvalds
2012-04-17 18:12     ` kernel panic after suspend/resume Sven Joachim
2012-04-17 19:50       ` Linus Torvalds
2012-04-17 22:13         ` Thomas Gleixner
2012-04-18  5:27           ` Sven Joachim
2012-04-17 21:21     ` kernel panic after suspend/resume (was: Linux 3.4-rc3) Rafael J. Wysocki
2012-04-18  8:22       ` kernel panic after suspend/resume Sven Joachim
2012-04-18  9:36         ` Rafael J. Wysocki
2012-04-18 10:08         ` Thomas Gleixner
2012-04-18 11:03           ` Sven Joachim
2012-04-18 12:07           ` [tip:timers/urgent] tick: Fix oneshot broadcast setup really tip-bot for Thomas Gleixner
2012-04-18 13:19             ` Shilimkar, Santosh
2012-04-18 14:18               ` Santosh Shilimkar
2012-04-18 15:31                 ` Thomas Gleixner
2012-04-18 15:51                   ` Santosh Shilimkar
2012-04-19  2:27                   ` Suresh Siddha
2012-04-19  8:29                     ` Thomas Gleixner
2012-04-19 10:14                       ` Santosh Shilimkar
2012-04-19 10:37                       ` Sven Joachim
2012-04-19 19:38                     ` [tip:timers/urgent] tick: Fix the spurious broadcast timer ticks after resume tip-bot for Suresh Siddha
2012-04-19 19:37                   ` tip-bot for Thomas Gleixner [this message]

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=tip-b9a6a23566960d0dd3f51e2e68b472cd61911078@git.kernel.org \
    --to=tglx@linutronix.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=santosh.shilimkar@ti.com \
    --cc=suresh.b.siddha@intel.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.