linux-kernel - Re: [PATCH] alarmtimer: check RTC features instead of ops

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: <YJAX60DSp/imRstL@piout.net>
Date:   Mon, 3 May 2021 17:34:03 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     John Stultz <john.stultz@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] alarmtimer: check RTC features instead of ops

Hello,

On 30/04/2021 10:59:53+0200, Thomas Gleixner wrote:
> On Fri, Apr 30 2021 at 10:10, Alexandre Belloni wrote:
> > On 30/04/2021 09:16:40+0200, Thomas Gleixner wrote:
> >> On Thu, Apr 29 2021 at 23:49, Alexandre Belloni wrote:
> >> > Test RTC_FEATURE_ALARM instead of relying on ops->set_alarm to know whether
> >> > alarms are available.
> >> >
> >> > Fixes: 7ae41220ef58 ("rtc: introduce features bitfield")
> >> > Signed-off-by: Alexandre Belloni <alexandre.belloni@...tlin.com>
> >> > ---
> >> > Hello,
> >> >
> >> > This doesn't seem much but this solve an issue where following a change in the
> >> > RTC driver, this part of the code will think the RTC is alarm capable while it
> >> > is not, then breaking the alarmtimer functionnality.
> >> 
> >> So a driver has the set_alarm() callback but does not advertise
> >> RTC_FEATURE_ALARM for whatever reason and why ever this makes sense.
> >> 
> >
> > No, it would be the other way around. The issue happens when you have
> > two RTCs, rtc0 is not alarm capable and rtc1 has alarms.
> >
> > The driver for rtc0 used to not have .set_alarm() to signal it didn't
> > support alarms, it then switched to RTC_FEATURE_ALARM, making the
> > alarmtimer code select that RTC instead of rtc1, breaking suspend/resume
> > on the platform.
> 
> I'm even more confused. So RTC0 does not have .set_alarm() but why does
> it turn on RTC_FEATURE_ALARM? I'm obviously misinterpreting the above...
> 

I'm sorry for not being clear.

With RTC0 not having alarms and RTC1 having alarms:

The previous situation was:

The driver for RTC0 didn't have any .set_alarm() to signel it doesn't
support alarms.
On registration, alarmtimer_rtc_add_device finds out it doesn't have the
.set_alarm() callback and doesn't select that RTC.
On registration of RTC1, alarmtimer_rtc_add_device finds .set_alarm()
and RTC1 is now the alarmtimer rtcdev.

The new situation is:

The driver for RTC0 always have .set_alarm() but clears
RTC_FEATURE_ALARM to signal it doesn't support alarms.
On registration, alarmtimer_rtc_add_device finds .set_alarm() and RTC0
is now the alarmtimer rtcdev, leading to an error when rtc_timer_start()
is called.

I hope this is clearer.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com