Patchwork RTC: Avoid races between RTC alarm wakeup and suspend.

login
register
mail settings
Submitter Neil Brown
Date July 30, 2012, 1:35 a.m.
Message ID <20120730113547.2c425ea9@notabene.brown>
Download mbox | patch
Permalink /patch/173948/
State New
Headers show

Comments

Neil Brown - July 30, 2012, 1:35 a.m.
If an RTC alarm fires just as suspend is happening, it is possible for
suspend to complete and the alarm to be missed.

To avoid the race, we must register the event with the PM core.

As the event is made visible to userspace through a thread which is
only scheduled by the interrupt, we need a pm_stay_awake/pm_relax
pair preventing suspend from the interrupt until the thread completes
its work.

Signed-off-by: NeilBrown <neilb@suse.de>

--
This makes the pm_wakeup_event() call in cmos_interrupt unnecessary as it
provides suspend protection for all RTCs that use rtc_update_irq.

I think the pm_stay_awake//pm_relax is needed - just pm_wakup_event() is 
theoretically not sufficient.

This is because there is no guarantee (that I know of) that the workqueue
thread will actually get scheduled before 'suspend' takes over.

Thanks,
NeilBrown
Rafael J. Wysocki - July 30, 2012, 9:01 p.m.
On Monday, July 30, 2012, NeilBrown wrote:
> 
> If an RTC alarm fires just as suspend is happening, it is possible for
> suspend to complete and the alarm to be missed.
> 
> To avoid the race, we must register the event with the PM core.
> 
> As the event is made visible to userspace through a thread which is
> only scheduled by the interrupt, we need a pm_stay_awake/pm_relax
> pair preventing suspend from the interrupt until the thread completes
> its work.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> 
> --
> This makes the pm_wakeup_event() call in cmos_interrupt unnecessary as it
> provides suspend protection for all RTCs that use rtc_update_irq.

Care to remove the call in cmos_interrupt(), then?

> I think the pm_stay_awake//pm_relax is needed - just pm_wakup_event() is 
> theoretically not sufficient.
> 
> This is because there is no guarantee (that I know of) that the workqueue
> thread will actually get scheduled before 'suspend' takes over.

I think you are right.

Thanks,
Rafael


> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index eb415bd..9592b93 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -582,6 +582,7 @@ enum hrtimer_restart rtc_pie_update_irq(struct hrtimer *timer)
>  void rtc_update_irq(struct rtc_device *rtc,
>  		unsigned long num, unsigned long events)
>  {
> +	pm_stay_awake(rtc->dev.parent);
>  	schedule_work(&rtc->irqwork);
>  }
>  EXPORT_SYMBOL_GPL(rtc_update_irq);
> @@ -844,6 +845,7 @@ void rtc_timer_do_work(struct work_struct *work)
>  
>  	mutex_lock(&rtc->ops_lock);
>  again:
> +	pm_relax(rtc->dev.parent);
>  	__rtc_read_time(rtc, &tm);
>  	now = rtc_tm_to_ktime(tm);
>  	while ((next = timerqueue_getnext(&rtc->timerqueue))) {
>

Patch

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index eb415bd..9592b93 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -582,6 +582,7 @@  enum hrtimer_restart rtc_pie_update_irq(struct hrtimer *timer)
 void rtc_update_irq(struct rtc_device *rtc,
 		unsigned long num, unsigned long events)
 {
+	pm_stay_awake(rtc->dev.parent);
 	schedule_work(&rtc->irqwork);
 }
 EXPORT_SYMBOL_GPL(rtc_update_irq);
@@ -844,6 +845,7 @@  void rtc_timer_do_work(struct work_struct *work)
 
 	mutex_lock(&rtc->ops_lock);
 again:
+	pm_relax(rtc->dev.parent);
 	__rtc_read_time(rtc, &tm);
 	now = rtc_tm_to_ktime(tm);
 	while ((next = timerqueue_getnext(&rtc->timerqueue))) {