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 <tglx@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;
 	}