[GIT pull] timer fixes for 3.4

[GIT pull] timer fixes for 3.4

[Thomas Gleixner]

Linus,

please pull the latest timers-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus


The itimer removal one is not strictly a fix, but I really wanted to
avoid a rebase of the urgent ones.

Thanks,

	tglx

------------------>
Martin Schwidefsky (1):
      proc: stats: Use arch_idle_time for idle and iowait times if available

Neal Cardwell (1):
      nohz: Fix stale jiffies update in tick_nohz_restart()

Sasikantha babu (1):
      itimer: Schedule silent NULL pointer fixup in setitimer() for removal

Suresh Siddha (1):
      clockevents: tTack broadcast device mode change in tick_broadcast_switch_to_oneshot()

Thomas Gleixner (3):
      tick: Document TICK_ONESHOT config option
      itimer: Use printk_once instead of WARN_ONCE
      Revert "clocksource: Load the ACPI PM clocksource asynchronously"


 Documentation/feature-removal-schedule.txt |    8 ++++++
 drivers/clocksource/acpi_pm.c              |   24 ++++++-------------
 fs/proc/stat.c                             |   34 +++++++++++++++++++++++-----
 kernel/itimer.c                            |    8 +++++-
 kernel/time/Kconfig                        |    4 +++
 kernel/time/tick-broadcast.c               |    4 ++-
 kernel/time/tick-sched.c                   |    4 +-
 7 files changed, 59 insertions(+), 27 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 0cad480..32fae81 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -529,3 +529,11 @@ When:	3.5
 Why:	The old kmap_atomic() with two arguments is deprecated, we only
 	keep it for backward compatibility for few cycles and then drop it.
 Who:	Cong Wang <amwang@redhat.com>
+
+----------------------------
+
+What:	setitimer accepts user NULL pointer (value)
+When:	3.6
+Why:	setitimer is not returning -EFAULT if user pointer is NULL. This
+	violates the spec.
+Who:	Sasikantha Babu <sasikanth.v19@gmail.com>
diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index 82e8820..6b5cf02 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -23,7 +23,6 @@
 #include <linux/init.h>
 #include <linux/pci.h>
 #include <linux/delay.h>
-#include <linux/async.h>
 #include <asm/io.h>
 
 /*
@@ -180,15 +179,17 @@ static int verify_pmtmr_rate(void)
 /* Number of reads we try to get two different values */
 #define ACPI_PM_READ_CHECKS 10000
 
-static void __init acpi_pm_clocksource_async(void *unused, async_cookie_t cookie)
+static int __init init_acpi_pm_clocksource(void)
 {
 	cycle_t value1, value2;
 	unsigned int i, j = 0;
 
+	if (!pmtmr_ioport)
+		return -ENODEV;
 
 	/* "verify" this timing source: */
 	for (j = 0; j < ACPI_PM_MONOTONICITY_CHECKS; j++) {
-		usleep_range(100 * j, 100 * j + 100);
+		udelay(100 * j);
 		value1 = clocksource_acpi_pm.read(&clocksource_acpi_pm);
 		for (i = 0; i < ACPI_PM_READ_CHECKS; i++) {
 			value2 = clocksource_acpi_pm.read(&clocksource_acpi_pm);
@@ -202,34 +203,25 @@ static void __init acpi_pm_clocksource_async(void *unused, async_cookie_t cookie
 			       " 0x%#llx, 0x%#llx - aborting.\n",
 			       value1, value2);
 			pmtmr_ioport = 0;
-			return;
+			return -EINVAL;
 		}
 		if (i == ACPI_PM_READ_CHECKS) {
 			printk(KERN_INFO "PM-Timer failed consistency check "
 			       " (0x%#llx) - aborting.\n", value1);
 			pmtmr_ioport = 0;
-			return;
+			return -ENODEV;
 		}
 	}
 
 	if (verify_pmtmr_rate() != 0){
 		pmtmr_ioport = 0;
-		return;
+		return -ENODEV;
 	}
 
-	clocksource_register_hz(&clocksource_acpi_pm,
+	return clocksource_register_hz(&clocksource_acpi_pm,
 						PMTMR_TICKS_PER_SEC);
 }
 
-static int __init init_acpi_pm_clocksource(void)
-{
-	if (!pmtmr_ioport)
-		return -ENODEV;
-
-	async_schedule(acpi_pm_clocksource_async, NULL);
-	return 0;
-}
-
 /* We use fs_initcall because we want the PCI fixups to have run
  * but we still need to load before device_initcall
  */
diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index 6a0c62d..64c3b31 100644
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@ -18,19 +18,39 @@
 #ifndef arch_irq_stat
 #define arch_irq_stat() 0
 #endif
-#ifndef arch_idle_time
-#define arch_idle_time(cpu) 0
-#endif
+
+#ifdef arch_idle_time
+
+static cputime64_t get_idle_time(int cpu)
+{
+	cputime64_t idle;
+
+	idle = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE];
+	if (cpu_online(cpu) && !nr_iowait_cpu(cpu))
+		idle += arch_idle_time(cpu);
+	return idle;
+}
+
+static cputime64_t get_iowait_time(int cpu)
+{
+	cputime64_t iowait;
+
+	iowait = kcpustat_cpu(cpu).cpustat[CPUTIME_IOWAIT];
+	if (cpu_online(cpu) && nr_iowait_cpu(cpu))
+		iowait += arch_idle_time(cpu);
+	return iowait;
+}
+
+#else
 
 static u64 get_idle_time(int cpu)
 {
 	u64 idle, idle_time = get_cpu_idle_time_us(cpu, NULL);
 
-	if (idle_time == -1ULL) {
+	if (idle_time == -1ULL)
 		/* !NO_HZ so we can rely on cpustat.idle */
 		idle = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE];
-		idle += arch_idle_time(cpu);
-	} else
+	else
 		idle = usecs_to_cputime64(idle_time);
 
 	return idle;
@@ -49,6 +69,8 @@ static u64 get_iowait_time(int cpu)
 	return iowait;
 }
 
+#endif
+
 static int show_stat(struct seq_file *p, void *v)
 {
 	int i, j;
diff --git a/kernel/itimer.c b/kernel/itimer.c
index 22000c3..8d262b4 100644
--- a/kernel/itimer.c
+++ b/kernel/itimer.c
@@ -284,8 +284,12 @@ SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value,
 	if (value) {
 		if(copy_from_user(&set_buffer, value, sizeof(set_buffer)))
 			return -EFAULT;
-	} else
-		memset((char *) &set_buffer, 0, sizeof(set_buffer));
+	} else {
+		memset(&set_buffer, 0, sizeof(set_buffer));
+		printk_once(KERN_WARNING "%s calls setitimer() with new_value NULL pointer."
+			    " Misfeature support will be removed\n",
+			    current->comm);
+	}
 
 	error = do_setitimer(which, &set_buffer, ovalue ? &get_buffer : NULL);
 	if (error || !ovalue)
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index 2cf9cc7..a20dc8a 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -1,6 +1,10 @@
 #
 # Timer subsystem related configuration options
 #
+
+# Core internal switch. Selected by NO_HZ / HIGH_RES_TIMERS. This is
+# only related to the tick functionality. Oneshot clockevent devices
+# are supported independ of this.
 config TICK_ONESHOT
 	bool
 
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index e883f57..bf57abd 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -575,10 +575,12 @@ void tick_broadcast_switch_to_oneshot(void)
 	unsigned long flags;
 
 	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
+
+	tick_broadcast_device.mode = TICKDEV_MODE_ONESHOT;
+
 	if (cpumask_empty(tick_get_broadcast_mask()))
 		goto end;
 
-	tick_broadcast_device.mode = TICKDEV_MODE_ONESHOT;
 	bc = tick_broadcast_device.evtdev;
 	if (bc)
 		tick_broadcast_setup_oneshot(bc);
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3526038..6a3a5b9 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -534,9 +534,9 @@ static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)
 				hrtimer_get_expires(&ts->sched_timer), 0))
 				break;
 		}
-		/* Update jiffies and reread time */
-		tick_do_update_jiffies64(now);
+		/* Reread time and update jiffies */
 		now = ktime_get();
+		tick_do_update_jiffies64(now);
 	}
 }
 

Re: [GIT pull] timer fixes for 3.4

[Linus Torvalds]

On Thu, Apr 12, 2012 at 3:06 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The itimer removal one is not strictly a fix, but I really wanted to
> avoid a rebase of the urgent ones.

Btw, I think that setitimer NULL pointer removal commit is crap.

If people actually do rely on the NULL pointer thing, we're not
"scheduling it for removal". And we most *definitely* aren't
scheduling it for removal for some short timeframe like 3.6.

That's not how ABI's work. If it has become something people rely on,
it now *is* part of the ABI, and no amount of "violates the spec"
matters what-so-ever.

"The spec" is paper - and worthless. What people actually *do* is all
that matters.

                          Linus

Re: [GIT pull] timer fixes for 3.4

[Thomas Gleixner]

On Thu, 12 Apr 2012, Linus Torvalds wrote:

> On Thu, Apr 12, 2012 at 3:06 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > The itimer removal one is not strictly a fix, but I really wanted to
> > avoid a rebase of the urgent ones.
> 
> Btw, I think that setitimer NULL pointer removal commit is crap.
> 
> If people actually do rely on the NULL pointer thing, we're not
> "scheduling it for removal". And we most *definitely* aren't
> scheduling it for removal for some short timeframe like 3.6.
> 
> That's not how ABI's work. If it has become something people rely on,
> it now *is* part of the ABI, and no amount of "violates the spec"
> matters what-so-ever.
> 
> "The spec" is paper - and worthless. What people actually *do* is all
> that matters.

I ran it through all the various (outdated) distros I have handy and
the printk didn't show once.

I tried to figure out the reason for this NULL pointer thing, but
there is no trace of it on the intarwebs at all.

Thanks,

	tglx

Re: [GIT pull] timer fixes for 3.4

[Linus Torvalds]

On Thu, Apr 12, 2012 at 3:26 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> I ran it through all the various (outdated) distros I have handy and
> the printk didn't show once.
>
> I tried to figure out the reason for this NULL pointer thing, but
> there is no trace of it on the intarwebs at all.

Ok. If we don't see any reports of messages, we can certainly remove it.

That said, would people actually *report* those messages?

In general, for things like this, it's probably better to just make
the change (especially if you have several distros you can test), and
then add a printk_once() for the case that changed. Then, if people
actually report it as some program stopping to work, the dmesg
hopefully clues us in about the reason for the program not working.
But that would have needed to happen during the merge window, it's too
late now.

Whatever. We'll see if somebody reports the message.

                     Linus

Re: [GIT pull] timer fixes for 3.4

[Thomas Gleixner]

On Thu, 12 Apr 2012, Linus Torvalds wrote:

> On Thu, Apr 12, 2012 at 3:26 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > I ran it through all the various (outdated) distros I have handy and
> > the printk didn't show once.
> >
> > I tried to figure out the reason for this NULL pointer thing, but
> > there is no trace of it on the intarwebs at all.
> 
> Ok. If we don't see any reports of messages, we can certainly remove it.
> 
> That said, would people actually *report* those messages?
> 
> In general, for things like this, it's probably better to just make
> the change (especially if you have several distros you can test), and
> then add a printk_once() for the case that changed. Then, if people

I changed it to a printk_once() already.

> actually report it as some program stopping to work, the dmesg
> hopefully clues us in about the reason for the program not working.
> But that would have needed to happen during the merge window, it's too
> late now.

Yeah, sorry. I queued it and missed to send it along in time, then
queued other real fixes on top of it. Feel free to revert it and i put
it up for 3.5

Thanks,

	tglx

Re: [GIT pull] timer fixes for 3.4

[Linus Torvalds]

On Thu, Apr 12, 2012 at 3:39 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> That said, would people actually *report* those messages?
>>
>> In general, for things like this, it's probably better to just make
>> the change (especially if you have several distros you can test), and
>> then add a printk_once() for the case that changed. Then, if people
>
> I changed it to a printk_once() already.

No, I meant that the whole message should probably have been added
when actually changing the semantics.

If you have good reason to believe that some ABI change (a) does not
actually have any reason to break anything and (b) worth doing, then I
think it should just have been done (but during the merge window only,
of course).

And if (a) or (b) aren't true, then we're not going to change the ABI
at all, so the whole point is moot.

The printk_once (or, for that case WARN_ON_ONCE() may even be
worthwhile) would then just be a "oops, we were wrong" kind of
message, and would just mean that the commit would be reverted.

I think the whole "let's deprecate this six months into the future" is
unnecessary. Yes, it may well be worth doing for something with bigger
consequences, but I think that for something like this, it's just
overthinking the issue.

If it really is something we want to fix, I think it's much better to
just say "let's fix it, and if somebody notices, we'll have to go
back". The printk_once or WARN_ON is then just a polite way to avoid
having people have to bisect to it etc if it's subtle (and then we
would plan to remove *that* later).

                            Linus

Re: [GIT pull] timer fixes for 3.4

[Thomas Gleixner]

On Thu, 12 Apr 2012, Linus Torvalds wrote:

> On Thu, Apr 12, 2012 at 3:39 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >>
> >> That said, would people actually *report* those messages?
> >>
> >> In general, for things like this, it's probably better to just make
> >> the change (especially if you have several distros you can test), and
> >> then add a printk_once() for the case that changed. Then, if people
> >
> > I changed it to a printk_once() already.
> 
> No, I meant that the whole message should probably have been added
> when actually changing the semantics.
> 
> If you have good reason to believe that some ABI change (a) does not
> actually have any reason to break anything and (b) worth doing, then I
> think it should just have been done (but during the merge window only,
> of course).
> 
> And if (a) or (b) aren't true, then we're not going to change the ABI
> at all, so the whole point is moot.
> 
> The printk_once (or, for that case WARN_ON_ONCE() may even be
> worthwhile) would then just be a "oops, we were wrong" kind of
> message, and would just mean that the commit would be reverted.
> 
> I think the whole "let's deprecate this six months into the future" is
> unnecessary. Yes, it may well be worth doing for something with bigger
> consequences, but I think that for something like this, it's just
> overthinking the issue.
> 
> If it really is something we want to fix, I think it's much better to
> just say "let's fix it, and if somebody notices, we'll have to go
> back". The printk_once or WARN_ON is then just a polite way to avoid
> having people have to bisect to it etc if it's subtle (and then we
> would plan to remove *that* later).

Fair enough.

Though last time I tried to do that (IIRC, it was a sanity check on a
timespec) I was forced to go the deprecation way ....

Times are changing :)

      tglx

[GIT pull] timer fixes for 3.4

[Thomas Gleixner]

Linus,

please pull the latest timers-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus

Thanks,

	tglx

------------------>
Suresh Siddha (1):
      tick: Fix the spurious broadcast timer ticks after resume

Thomas Gleixner (2):
      tick: Fix oneshot broadcast setup really
      tick: Ensure that the broadcast device is initialized


 kernel/time/tick-broadcast.c |   13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index bf57abd..f113755 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -346,7 +346,8 @@ int tick_resume_broadcast(void)
 						     tick_get_broadcast_mask());
 			break;
 		case TICKDEV_MODE_ONESHOT:
-			broadcast = tick_resume_broadcast_oneshot(bc);
+			if (!cpumask_empty(tick_get_broadcast_mask()))
+				broadcast = tick_resume_broadcast_oneshot(bc);
 			break;
 		}
 	}
@@ -373,6 +374,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);
 }
 
@@ -531,7 +535,6 @@ void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 		int was_periodic = bc->mode == CLOCK_EVT_MODE_PERIODIC;
 
 		bc->event_handler = tick_handle_oneshot_broadcast;
-		clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
 
 		/* Take the do_timer update */
 		tick_do_timer_cpu = cpu;
@@ -549,6 +552,7 @@ void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 			   to_cpumask(tmpmask));
 
 		if (was_periodic && !cpumask_empty(to_cpumask(tmpmask))) {
+			clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
 			tick_broadcast_init_next_event(to_cpumask(tmpmask),
 						       tick_next_period);
 			tick_broadcast_set_event(tick_next_period, 1);
@@ -577,15 +581,10 @@ void tick_broadcast_switch_to_oneshot(void)
 	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
 
 	tick_broadcast_device.mode = TICKDEV_MODE_ONESHOT;
-
-	if (cpumask_empty(tick_get_broadcast_mask()))
-		goto end;
-
 	bc = tick_broadcast_device.evtdev;
 	if (bc)
 		tick_broadcast_setup_oneshot(bc);
 
-end:
 	raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
 }