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, 29 Jul 2020 08:22:36 -0400
From:   Prarit Bhargava <prarit@...hat.com>
To:     corbet@....net, pmladek@...e.com, rostedt@...dmis.org,
        sergey.senozhatsky@...il.com
Cc:     chunyan.zhang@...soc.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, orsonzhai@...il.com,
        zhang.lyra@...il.com
Subject: Re: [PATCH V13] printk: Add monotonic, boottime, and realtime timestamps

  Chunyan Zhang <zhang.lyra@...il.com> wrote:
> From: Prarit Bhargava <prarit@...hat.com>
> 
> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
> timestamp to printk messages.  The local hardware clock loses time each
> day making it difficult to determine exactly when an issue has occurred in
> the kernel log, and making it difficult to determine how kernel and
> hardware issues relate to each other in real time.
> 
> Make printk output different timestamps by adding options for no
> timestamp, the local hardware clock, the monotonic clock, the boottime
> clock, and the real clock.  Allow a user to pick one of the clocks by
> using the printk.time kernel parameter.  Output the type of clock in
> /sys/module/printk/parameters/time so userspace programs can interpret the
> timestamp.
> 
> v13: This patch seems have being forgotten for 3 years. Rebase it on
> the latest kernel v5.8, reolve conflicts and fix compiling errors.
> Change code to adapt new printk_time usage.
> Petr's concern on printk_time is addressed by current version of kernel, too.

Lyra,

Copying a reply I sent to Orson who sent me this patch privately this
morning with some additional information.

ISTR the reason that this was dropped was because of the a problem with
the way systemd read the kernel's timestamps.  It got the attention of
Linus, and it was then pulled from the tree.

I need to go back and review the entire thread as it's been several years
since we had the discussion although ISTR someone mentioning that doing two
timestamps would not be a problem for systemd.

For example,

[48551.015086]

would be

[48551.015086] m[xxxx.xxxx]

for the monotonic clock timestamp, and

[48551.015086] b[xxxx.xxxx]

for the boottime clock, etc.

P.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ