linux-kernel - Re: __rtc_read_alarm missing month/year field bug?

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]

Date:	Thu, 21 Jul 2016 15:52:02 -0400
From:	Joe Lawrence <joe.lawrence@...hat.com>
To:	joe.lawrence@...hat.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	rtc-linux@...glegroups.com
Cc:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: __rtc_read_alarm missing month/year field bug?

On 07/19/2016, Alexandre Belloni wrote:
>
> Well like said in my previous mail, I don't think the rollover is the
> issue here but I'm interested in knowing what conditions are leading >
to endless interrupts.

Hi Alexandre,

Unfortunately I've switched employers so I no longer have access to the
hardware, but if I remember correctly the scenario went like this:

  - boot machine with RTC alarm set in far future
  - run 'hwclock' user program
    - hwclock sync to clock tick
      - RTC_UIE_ON
      - RTC_UIE_OFF
  - kernel sees RTC alarm is outstanding
    - hpet_rtc_interrupt's start streaming in

In the case of this hardware platform, there was a problem with the CMOS
RTC read such that  hpet_rtc_interrupt / rtc_cmos_read believed that the
RTC was busy updating ... that code would delay long enough that the
next HPET rtc interrupt would come in right behind it and choke the CPU
from scheduling anything else.

That platform-specific bug aside, I thought I would report this
strangeness in case it was a real bug -- looks like I didn't fully
consider the rollover case.

-- Joe