linux-kernel - Re: [PATCH RESEND v3 2/7] rtc-mc146818-lib: fix RTC presence check

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 10 Dec 2021 20:05:38 +0100
From:   Mateusz Jończyk <mat.jonczyk@...pl>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     linux-kernel@...r.kernel.org, linux-rtc@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [PATCH RESEND v3 2/7] rtc-mc146818-lib: fix RTC presence check

W dniu 10.12.2021 o 16:26, Alexandre Belloni pisze:
> Hi,
>
> On 25/11/2021 23:12:42+0100, Mateusz Jończyk wrote:
>> W dniu 24.11.2021 o 23:31, Alexandre Belloni pisze:
>>> Hello,
>>>
>>> By moving this patch later on in the series, you'd avoid the subsequent
>>> refactor. I think this would be better for bisection later on.
>> Hi,
>>
>> There are three issues I'm trying to fix in this series:
>>
>> 1. (less important) Insufficient locking in cmos_set_alarm()
>> 2. misdetection of the RTC CMOS as broken on some motherboards,
>> 3. reading / writing of the RTC alarm time during RTC update-in-progress.
>>
>> Do you mean I should drop the patch
>>     nr 2. ("rtc-mc146818-lib: fix RTC presence check")
>> and instead straight away introduce mc146818_avoid_UIP() with the new approach (as in patch 3 in the series),
>> then modify mc146818_get_time() to use it (as in patch 4 - fixing issue nr 2),
>> then modify cmos_read_alarm / cmos_set_alarm to use mc146818_avoid_UIP() (patches 5-6, fixing issue no. 3)?
>>
>> I was afraid this risks some confusion what is being fixed when.
> I realize I never replied to this. This is fine, I'm planning to apply
> the whole series once the few comments are fixed.

Great!

I've got other things mostly sorted out and tested, so I'll send a v4 shortly after some last-minute checks.

> We'll probably get some breakage later on because many RTCs using this
> driver are not adhering to the spec.
>
Thanks,

Mateusz