linux-kernel - Re: [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot

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: <595323bb-85a4-973f-5ca6-aaa80e6000c5@android.com>
Date:   Tue, 28 Nov 2017 12:29:38 -0800
From:   Mark Salyzyn <salyzyn@...roid.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Prarit Bhargava <prarit@...hat.com>,
        Petr Mladek <pmladek@...e.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Joe Perches <joe@...ches.com>
Subject: Re: [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps
 during boot

On 11/28/2017 11:45 AM, Steven Rostedt wrote:
> On Tue, 28 Nov 2017 11:10:02 -0800
> Mark Salyzyn <salyzyn@...roid.com> wrote:
>
>> There is no guarantee of sequential order of delivery for kernel prints.
> But isn't the timestamp taken with the logbuf_lock, and then delivered
> to the printk buffer? That would guarantee that all events will be in
> order, and the timestamps be sequential. They are serialized by the
> logbuf_lock.
>
> -- Steve

To get closer to a sequential order of event delivery by timestamp, you 
really should take a global timestamp (I know, local clock is _not_ a 
global timestamp) first thing and as close to the event as possible, 
before anything else, and outside of a lock which is merely a 
synchronization action.

A) event came first, got preempted by the scheduler before lock.

B) multiple events came in order while lock held, random selection of 
which one gets the lock once released.

C) scheduling differences between FIFO, BATCH, low priority, cgroup 
limits, interrupt, especially since an event is usually generated 
_after_ the fact related to an activity.

We do not have a guarantee of sequential order, outside the scope of 
this RFC. We accept this behavior as it is good enough for the most 
part, and we are all smart adults here, we can figure it out when things 
get strange.

-- Mark