linux.git/drivers/rtc/interface.c, branch v3.2-rc7

rtc: Expire alarms after the time is set.

2011-12-13T20:26:11+00:00

If the alarm time programming in the rtc is ever in the past, it won't fire,
and any other alarm will be queued after it so they won't fire either.

So any time that the alarm might be in the past, we need to trigger
the irq handler to ensure the old alarm is cleared and the timer queue
is fully in the future.

This can happen:
 - when we first initialise the alarm
 - when we set the time in the rtc.

so follow both of these by scheduling the timer work function.

CC: stable@kernel.org
Signed-off-by: NeilBrown 
[Also catch set_mmss case -jstultz]
Signed-off-by: John Stultz

Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2011-12-06T00:53:43+00:00

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clockevents: Set noop handler in clockevents_exchange_device()
  tick-broadcast: Stop active broadcast device when replacing it
  clocksource: Fix bug with max_deferment margin calculation
  rtc: Fix some bugs that allowed accumulating time drift in suspend/resume
  rtc: Disable the alarm in the hardware

rtc: Disable the alarm in the hardware

2011-11-23T03:25:43+00:00

Currently, the RTC code does not disable the alarm in the hardware.

This means that after a sequence such as the one below (the files are in the
RTC sysfs), the box will boot up after 2 minutes even though we've
asked for the alarm to be turned off.

	# echo $((`cat since_epoch`)+120) > wakealarm
	# echo 0 > wakealarm
	# poweroff

Fix this by disabling the alarm when there are no timers to run.

Cc: stable@kernel.org
Cc: John Stultz 
Signed-off-by: Rabin Vincent 
Signed-off-by: John Stultz

rtc: Add module.h to implicit users in drivers/rtc

2011-10-31T23:31:28+00:00

The module.h was implicitly everywhere, but when we clean
that up, the implicit users will compile fail; fix them up
in advance.

Signed-off-by: Paul Gortmaker

rtc: fix hrtimer deadlock

2011-07-26T23:49:42+00:00

Ben reported a lockup related to rtc. The lockup happens due to:

CPU0                                        CPU1

rtc_irq_set_state()			    __run_hrtimer()
  spin_lock_irqsave(&rtc->irq_task_lock)    rtc_handle_legacy_irq();
					      spin_lock(&rtc->irq_task_lock);
  hrtimer_cancel()
    while (callback_running);

So the running callback never finishes as it's blocked on
rtc->irq_task_lock.

Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while
waiting for the callback.  Fix this for both rtc_irq_set_state() and
rtc_irq_set_freq().

Signed-off-by: Thomas Gleixner 
Reported-by: Ben Greear 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: limit frequency

2011-07-26T23:49:42+00:00

Due to the hrtimer self rearming mode a user can DoS the machine simply
because it's starved by hrtimer events.

The RTC hrtimer is self rearming.  We really need to limit the frequency
to something sensible.

Signed-off-by: Thomas Gleixner 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: Ben Greear 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: handle errors correctly in rtc_irq_set_state()

2011-07-26T23:49:41+00:00

The code checks the correctness of the parameters, but unconditionally
arms/disarms the hrtimer.

The result is that a random task might arm/disarm rtc timer and surprise
the real owner by either generating events or by stopping them.

Signed-off-by: Thomas Gleixner 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: Ben Greear 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: Limit RTC PIE frequency

2011-07-26T21:50:01+00:00

The RTC pie hrtimer is self rearming. We really need to limit the
frequency to something sensible. Thus limit it to the 8192Hz max
value from the rtc man documentation

Cc: Willy Tarreau 
Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner 
[jstultz: slightly reworked to use RTC_MAX_FREQ value]
Signed-off-by: John Stultz

rtc: Fix hrtimer deadlock

2011-07-26T21:49:59+00:00

Ben reported a lockup related to rtc. The lockup happens due to:

CPU0                                        CPU1

rtc_irq_set_state()			    __run_hrtimer()
  spin_lock_irqsave(&rtc->irq_task_lock)    rtc_handle_legacy_irq();
					      spin_lock(&rtc->irq_task_lock);
  hrtimer_cancel()
    while (callback_running);

So the running callback never finishes as it's blocked on
rtc->irq_task_lock.

Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while
waiting for the callback. Fix this for both rtc_irq_set_state() and
rtc_irq_set_freq().

Cc: stable@kernel.org
Reported-by: Ben Greear 
Signed-off-by: Thomas Gleixner 
Signed-off-by: John Stultz

rtc: Handle errors correctly in rtc_irq_set_state()

2011-07-26T21:49:57+00:00

In rtc_irq_set_state, the code checks the correctness of the parameters,
but then goes on to unconditionally arms/disarms the hrtimer. Thus a
random task might arm/disarm rtc timer and surprise the real owner by
either generating events or by stopping them.

Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: John Stultz