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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.11.1511171036130.3761@nanos>
Date:	Tue, 17 Nov 2015 11:06:47 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Lee, Zhuo-hao" <zhuo-hao.lee@...el.com>
cc:	John Stultz <john.stultz@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"zhuohao.lee82@...il.com" <zhuohao.lee82@...il.com>
Subject: RE: [PATCH v2] alarmtimer: fix unexpected rtc interrupt when system
 resume from S3

On Tue, 17 Nov 2015, Lee, Zhuo-hao wrote:

Can you please fix your e-mail client to do proper line breaks around
80 char?

> >> (1). alarmtimer create a rtc wake up timer however alarmtimer won't
> >>      remove that timer if the system wake up earlier
> 
> > That's hardly a bug. That's a slight incorrectness which needs to be fixed.
> 
> I think this timer is useless after system resume. For the
> correctness, I think it should be fixed.  Do you agree? Or do you
> have any other suggestions? :)

Care to read what I wrote?

> >   ... That's a slight incorrectness which needs to be fixed.

> >> (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.
> 
> > And that's the real interesting question. Why is hpet_rtc_interrupt
> > continously triggered?

> I think this is caused by driver implementation. 
> My explanation for the continuous  hpet_rtc_interrupt():
> 1. In hpet_rtc_timer_init(), it will set "delta" to 1/64 seconds in
>    AIE mode (about 16ms, because of the value DEFAULT_RTC_SHIFT),
>    that will cause hpet_rtc_interrupt() be triggered in every 16ms
>    if the wakeup time (global variable hpet_alarm_time) is not
>    reached.
> 
> 2. When someone calls rtc_timer_start (ex: alarmtimer_suspend ),
>    hpet driver will set timeout value (current time + delta) to
>    hpet_alarm_time, and then enable hpet timer.
>
> 3. In hpet_rtc_interrupt(), it will call hpet_rtc_timer_reinit() to
>    reinit timer and add "delta" to the hpet_t1_cmp for the next
>    timeout value ( so we will receive an interrupt after 16ms).
>
>    If hpet_alarm_time is reached, the irq_handler() will be called, the
>    hpet_rtc_flags will be set to 0 and the hpet timer will be
>    disable.
>
>    Otherwise, we will receive an interrupt in each 16ms.

Right. We cannot do much about it. So the changelog of this patch
wants some explanation. Something like this:

  This was noticed because the HPET RTC emulation fires an interrupt
  every 16ms up to the point where the alarm time is reached.
  
Simply because you wouldn't have noticed if the interrupt happened
after 2 hours.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/