Message ID | 1395963049-11923-1-git-send-email-john.stultz@linaro.org |
---|---|
State | Accepted |
Commit | cab5e127eef040399902caa8e1510795583fa03a |
Headers | show |
* John Stultz <john.stultz@linaro.org> wrote: > Ingo, > > After testing a patch queued for 3.15, I noticed there was a WARNON > message that I realized was triggered by one of my patches that came > in the 3.14 merge window. I'm not very happy to find this now, but > sadly here it is. The fix is luckily fairly simple and just falls > back to previous behavior. > > For tip/timers/urgent. No problem - I've applied your fix to timers/urgent and will get it to Linus later today, after a bit of testing. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 0aa4ce8..5b40279 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1435,7 +1435,8 @@ void update_wall_time(void) out: raw_spin_unlock_irqrestore(&timekeeper_lock, flags); if (clock_set) - clock_was_set(); + /* Have to call _delayed version, since in irq context*/ + clock_was_set_delayed(); } /**
Ingo, After testing a patch queued for 3.15, I noticed there was a WARNON message that I realized was triggered by one of my patches that came in the 3.14 merge window. I'm not very happy to find this now, but sadly here it is. The fix is luckily fairly simple and just falls back to previous behavior. For tip/timers/urgent. thanks -john In commit 47a1b796306356f35 (tick/timekeeping: Call update_wall_time outside the jiffies lock), we moved to calling clock_was_set() due to the fact that we were no longer holding the timekeeping or jiffies lock. However, there is still the problem that clock_was_set() triggers an IPI, which cannot be done from the timer's hard irq context, and will generate WARN_ON warnings. Apparently in my earlier testing, I'm guessing I didn't bump the dmesg log level, so I somehow missed the WARN_ONs. Thus we need to revert back to calling clock_was_set_delayed(). Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: John Stultz <john.stultz@linaro.org> --- kernel/time/timekeeping.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)