linux-kernel - RE: [PATCH v2] alarmtimer: fix unexpected rtc interrupt when system resume from S3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <12EF70CDEA59BA47AD9EC69F20130B3401AEC69D@PGSMSX103.gar.corp.intel.com>
Date:	Sat, 14 Nov 2015 14:12:53 +0000
From:	"Lee, Zhuo-hao" <zhuo-hao.lee@...el.com>
To:	John Stultz <john.stultz@...aro.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"zhuohao.lee82@...il.com" <zhuohao.lee82@...il.com>
Subject: RE: [PATCH v2] alarmtimer: fix unexpected rtc interrupt when system
 resume from S3

>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