linux-kernel - Re: [PATCH 1/2] printk: Store all three timestamps

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: <20200924114952.GA29288@alley>
Date:   Thu, 24 Sep 2020 13:49:52 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Prarit Bhargava <prarit@...hat.com>,
        Mark Salyzyn <salyzyn@...roid.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Orson Zhai <orsonzhai@...il.com>,
        Changki Kim <changki.kim@...sung.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] printk: Store all three timestamps

On Thu 2020-09-24 00:18:53, John Ogness wrote:
> On 2020-09-23, Petr Mladek <pmladek@...e.com> wrote:
> > printk() historically shows the timestamps from the monotonic clock.
> 
> printk() uses the local clock, not the monotonic clock.
> 
> > It is fast, available early during boot, in any context, and even
> > without using any lock.
> >
> > There are repeated requests [1][2][3] to show the timestamps from other
> > clocks. The main motivation is to make it easier to correlate the kernel
> > and userspace logs. Where userspace logs usually use the real time
> > clock.
> >
> > Unfortunately, it is not possible to simply replace the default clock.
> > Userspace tools, like journalctl, dmesg, expect to get the timestamps
> > from the mono via /dev/kmsg interface or syslog syscall [4].
> > Also administrators would be confused when logs from different
> > systems use different clocks depending on kernel version or
> > build option [5].
> >
> > As a result, the mono clock has to stay as the default clock
> > and has to be used in the current user interfaces.
> 
> Actually this series is changing the default clock from local to
> monotonic. I for one welcome this change (and wish ftrace would do it as
> well), but it is a change.

Good point! I expected that it is enough when boot timestamps are
monotonic.

IMHO, it is really important to use the same clock by printk() and
ftrace! Otherwise, it would be hard to match them.

Honestly, I do not know enough about the different clocks and their
users. My view is:

1. printk() needs a clock that is:

      + monotonic (always increasing)
      + lockless access
      + updated fast enough (precision)
      + available during early boot
      + match clock used by other kernel logs (ftrace)

2. ftrace needs a clock that is:

      + same requirements as for printk()
      + fast access to reduce performance problems

3. user space developers need:

   + real time clock to match userspace logs

Now, we have 4 clocks. IMHO, storing all 4 timestamps is not worth it.
We need at least two:

    + local, mono, or boot clock as legacy kernel timestamp
    + real clock to match timestamps from userspace tools

I am not able to say what clock is the best one for kernel timestamps.
The following questions come to my mind:

Is mono or boot clock fast enough for ftrace (performance wise)?
Is mono or boot clock available early enough during boot?
Is is boot clock acceptable as the default kernel clock?

IMHO, the boot clock is interesting because it has similar semantic
as the real time (running even during sleep). But I am not sure if
some developers do not rely on the mono clock or even local clock.

I guess that this need opinion from a wide audience or developers
experienced in many areas. I do not feel quialified to make
a decision.

Best Regards,
Petr