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:   Wed, 15 Nov 2017 09:42:48 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mark Salyzyn <salyzyn@...roid.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        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>
Subject: Re: [GIT pull] printk updates for 4.15

On Wed, Nov 15, 2017 at 8:26 AM, Mark Salyzyn <salyzyn@...roid.com> wrote:
>
> Maybe for completeness, but having it may straighten out a synchronization
> mess.
>
> [TL;DR]
>
> "If you have three watches, you will never know what time it is"(tm)
>
> Android peripherals with embedded firmware (camera, sensor hub, etc) all are
> run synchronized to boottime. If the firmware logs any data and it is
> propagated, we run into issues trying to triage firmware, kernel and user
> space temporal activities as each is on a different timebase.

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).

So I'd prefer that kind of "could we at least first try to improve on
the situation" over adding more complexity due to a historical
accident that people at the time didn't think would be so confusing..

I suspect a lot of people use CLOCK_MONOTONIC because it's

 (a) been around forever

 (b) is quicker than realtime

 (c) is monotonic (duh!) so you can sort things

but these users wouldn't _mind_ getting the BOOTTIME behavior. So
making CLOCK_MONOTONIC just do the BOOTTIME thing likely wouldn't
hurt.  They don't care about suspend.

In contrast, the people who now use BOOTTIME, probably use it exactly
_because_ they care about suspend, and may still want the
monotonicity, but they'd like something that still approaches wall
clock time at least in the _delta_.

So I'm pushing back on complexity here a bit. We *might* be able to
really just simplify things.

         Linus