>If you could, please CC me on future submissions? I need to add an entry to 
>MAINTAINERS >for alarmtimers. :)

Ok, I will do that on the future submissions :)

>> Before the system go to suspend (S3), if user create a timer with 
>> clockid CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM and set a "large" 
>> timeout value to this timer. The function alarmtimer_suspend will be 
>> called to setup a timeout value to RTC timer to avoid the system sleep 
>> over time. However, if the system wakeup early than RTC timeout, the RTC 
>> timer will not be cleared.
>> And this will cause the hpet_rtc_interrupt come unexpectedly until the 
>> RTC timeout. To fix this problem, just adding alarmtimer_resume to 
>> cancel the RTC timer.

>So conceptually the patch makes sense, though I'm not totally sure I 
>understand the failure you describe.

I had posted a small program which always hit this bug if system wake up 
earlier than setting time,
Did you receive it?
https://lkml.org/lkml/2015/11/8/326

>We have some alarmtimer set for 2 hours from now.
>We suspend, and the alarmtimer code sets an rtctimer to wake us up in
>2 hours week.
>We resume a few minutes later due to user interaction or other wakeups, but 
>the rtctimer is still set.
>A little less then two hours later (while the system has been awake the whole 
>time), the RTC hardware fires and we run the rtctimer.
>???? Something problematic here w/ the hpet_rtc_interrupt?

Yes. 
If application use timerfd_create(CLOCK_REALTIME_ALARM, 0) to create a timer, 
and use timerfd_settime() to set 2 hours timer. And then, the user just trigger 
the system go to suspend, this bug will be hit. 
Before the system go to suspend, alarmtimer will set "current time + 2hr" to 
rtc timer to avoid the system sleep over time. If the system wake up earlier 
than 2 hours (for example, user press the wake up key), the hpet_rtc_interrupt 
will be fired continuously until "current time + 2hr" reached. This abnormal 
interrupt will cost some system performance and should be avoided.

>The alarmtimer's hrtimer fires as normal.

>Again, your fix seems reasonable, but I also feel like when the RTC hardware 
>spuriously fires and we trigger the rtctimer >logic, there shouldn't be any 
>real problems there. So I want to make sure we're not covering up some 
>underlying issue w/ >this fix.

Agree, there have two problems on this bug:
(1). alarmtimer create a rtc wake up timer however alarmtimer won't remove that 
timer if the system wake up earlier
(2). rtc wake up timer will trigger hpet_rtc_interrupt continuously until timer 
timeout.
This patch only fixed (1). Fixing (1) can avoid (2).
However, The (2) is another story which it is not covered by this patch.


Thanks
Lee, Zhuo-hao

Reply via email to