linux-kernel - Re: [GIT pull] printk updates for 4.15

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:   Thu, 16 Nov 2017 01:37:41 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Mark Salyzyn <salyzyn@...roid.com>, Petr Mladek <pmladek@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Prarit Bhargava <prarit@...hat.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Stultz <john.stultz@...aro.org>
Subject: Re: [GIT pull] printk updates for 4.15

On Wed, 15 Nov 2017, Linus Torvalds wrote:
> 
> So I agree with all of this, but I wonder what actuall yuses that
> BOOTTIME to make it worth even synchronizing with.
> 
> I'm assuming it's some evdev user.
> 
> But I'm wondering if perhaps we could just simplify our own lives and
> make CLOCK_BOOTTIME and CLOCK_MONOTONIC just be the same.
> 
> And we'd make them be the same by making CLOCK_MONOTONIC act like
> CLOCK_BOOTTIME.
> 
> I doubt anybody would notice.
>
> At least we could _try_ that kind of system clock simplification.
> Maybe people would scream bloody murder and we'd have to revert, but
> wouldn't it be lovely to simplify the synchronization problem by just
> making it go away (well, at least for the BOOTTIME/MONOTONIC case).

Yes it would be lovely. I have some vague memories about having MONOTONIC
behave the same way as BOOTTIME in the early days of the generic
timekeeping infrastructure, high resolution timers and idle NOHZ work, 10+
years ago.

This broke stuff because the historic behaviour was to not advance on
resume and the change caused massive timer expiries right after resume
which confused the hell out of things, because timers fired immediately
which were not expected to fire as they were implicitely relying on suspend
not affecting clock monotonic.

So we reverted back to the old behaviour.

Soon after that, people complained about not being able to arm timers which
should expire after a resume or get access to the time spent there, but
they could not use REALTIME due to time jumps caused by DST and
whatever. So we introduced BOOTTIME.

In hindsight it might have been better not to do that, but now we have to
deal with it.

I'm a bit worried to change that because the behaviour difference of
MONOTONIC and BOOTTIME vs. suspend/resume is well documented all over the
place and there are explicit choices made in applications and libraries
which one of them to use for a particular problem. So I expect that some of
the surprises we've seen 10+ years ago still persist.

I'm also quite sure that there is kernel code which relies implicitely on
that behaviour. We surely can fix that, but it might be tedious to debug.

John?

Thanks,

	tglx