[PATCH] time: Revert to calling clock_was_set_delayed() while in irq context

[PATCH] time: Revert to calling clock_was_set_delayed() while in irq context

[John Stultz]

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(-)

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();
 }
 
 /**
-- 
1.8.3.2

Re: [PATCH] time: Revert to calling clock_was_set_delayed() while in irq context

[Ingo Molnar]

* 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

[tip:timers/urgent] time: Revert to calling clock_was_set_delayed () while in irq context

[tip-bot for John Stultz]

Commit-ID:  cab5e127eef040399902caa8e1510795583fa03a
Gitweb:     http://git.kernel.org/tip/cab5e127eef040399902caa8e1510795583fa03a
Author:     John Stultz <john.stultz@linaro.org>
AuthorDate: Thu, 27 Mar 2014 16:30:49 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 28 Mar 2014 08:07:07 +0100

time: Revert to calling clock_was_set_delayed() while in irq context

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().

Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1395963049-11923-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/time/timekeeping.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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();
 }
 
 /**