local_clock() cannot be reliably correlated to CLOCK_MONOTONIC, which is
used by user space, e.g. systemd, to create correlation timestamps.
There are multiple reasons:
- CLOCK_MONOTONIC is NTP adjusted, local_clock() not. Depending on the
calibration accuracy and uptime significant drift can be observed.
- CLOCK_MONOTONIC does not advance across suspend/resume for historical
reasons. local_clock() might or might not depending on the properties of
the underlying hardware counter.
Use the NMI safe accessor to clock MONOTONIC instead of local_clock(). The
access might be slower than local_clock(), but printk is not such a
performance critical hotpath that it matters.
Visible change:
The early boot timestamps are jiffies based longer than with local_clock()
depending on the platform. During suspend/resume the timestamp may become
stale when the underlying clocksource hardware is not flagged with
CLOCKSOURCE_SUSPEND_ACCESS_OK.
A horrible follow up patch demonstrates how that could be mitigated.
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
---
kernel/printk/printk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -624,7 +624,7 @@ static int log_store(int facility, int l
if (ts_nsec > 0)
msg->ts_nsec = ts_nsec;
else
- msg->ts_nsec = local_clock();
+ msg->ts_nsec = ktime_get_mono_fast_ns();
memset(log_dict(msg) + dict_len, 0, pad_len);
msg->len = size;
@@ -1631,7 +1631,7 @@ static bool cont_add(int facility, int l
cont.facility = facility;
cont.level = level;
cont.owner = current;
- cont.ts_nsec = local_clock();
+ cont.ts_nsec = ktime_get_mono_fast_ns();
cont.flags = flags;
}
