linux-kernel - Re: Time keeping while suspended in the presence of persistent clock drift

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]

Date:   Wed, 15 Dec 2021 23:33:10 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     John Stultz <john.stultz@...aro.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     Joel Daniels <jdaniels@...t.com>, Stephen Boyd <sboyd@...nel.org>,
        linux-kernel@...r.kernel.org,
        Alessandro Zummo <a.zummo@...ertech.it>,
        linux-rtc@...r.kernel.org, x86@...nel.org
Subject: Re: Time keeping while suspended in the presence of persistent
 clock drift

On Wed, Dec 15 2021 at 14:02, John Stultz wrote:
> On Wed, Dec 15, 2021 at 1:32 PM Alexandre Belloni
>> I'd rather lean towards the timekeeping code doing that. The RTC
>
> Heh, touche'!  :)
>
>> subsystem doesn't know which RTC has to be used.
>
> Though the RTC layer *is* the one that tracks which RTC is used, via
> the logic in drivers/rtc/class.c, and the timekeeping core already has
> adjtimex for timekeeping corrections, so if we're correcting
> underlying RTCs it seems such tuning would best be done in the RTC
> layer.
>
> Though how the persistent_clock interface ties into such corrections
> would be a separate thing.

Might be the final trigger to get rid of that leftover from the last
millenium?

Thanks,

        tglx