Re: [QUESTION] printk: time namespaces and printk timestamps

[Thomas Gleixner]

On Mon, May 25 2026 at 17:38, Thomas Weißschuh wrote:
> On 2026-05-25 15:29:01+0200, Petr Mladek wrote:
>
> Result:
> [    2.998937] test		(host console, non-namespaced)
> 0.873620599			(lsclocks --time monotonic in namespace)
> <12>[18446744071.708489] test	(/dev/kmsg in namespace)

Of course :)

>> > > > > I see two potential problems:
>> > > > > 
>> > > > > 1. printk() historically used a monotonic clock. I am not sure if any
>> > > > >    usespace application depends on it but there is a risk of breaking
>> > > > >    something.
>> > > > 
>> > > > >From the perspective of the namespaced process currently the timestamps
>> > > > from printk may in fact not be CLOCK_MONOTONIC.
>> > > 
>> > > The messages stored in the kernel ring buffer currently always have
>> > > monotonic timestamps.
>> > 
>> > "monotonic" as in "never decreases" (obious) or "CLOCK_MONOTONIC"?
>> > That is not actually well-documented I think.
>> > dmesg(1) assumes CLOCK_MONOTONIC.
>> 
>> Honestly, I do not know the details. printk() is calling local_clock()
>> which is a wrapper over sched_clock(). I think that it is based on
>> "CLOCK_MONOTONIC" but it is not precise because it is lockless.
>
> We have ktime_get_mono_fast_ns() which is also supposed to do this.
> The name would be clearer and it should be guaranteed to be
> CLOCK_MONOTONIC. But I don't know the details or history so this is just
> guesswork right now.

local_clock() is available slightly earlier than CLOCK_MONOTONIC and
contrary to CLOCK_MONOTONIC it is not NTP adjusted. So they drift apart,
which makes it actually annoying to correlate dmesg with actual time.

We had this discussion before:

  https://lore.kernel.org/lkml/20171115182657.383713029@xxxxxxxxxxxxx/

Tracing allows to select time, which _is_ very useful for correlation.

>> > As a real-world example, dmesg(1) uses clock_gettime(CLOCK_MONOTONIC) in
>> > its logic to format kmsg timestamps as wallcock/CLOCK_REALTIME ones:

That's absurd. There is no way dmesg(1) can map local_clock() to
REALTIME via MONOTONIC. Wishful thinking at best.

>> It should get fixed if we added the name space offset, similar
>> to commit 3ae700ecfae91331 ("fs/proc: apply the time namespace
>> offset to /proc/stat btime"). But we should use
>> timens_add_boottime_ns() which does not exist at the moment.

As long as printk uses local_clock() trying to apply a namespace offset is
completely moot.

local_clock() is basically CLOCK_MONOTONIC_RAW plus an offset, which is
something between 30-100ms. But it's actually not exact as the
calculation is slightly different and therefore drifts apart over time
slightly.

CLOCK_MONOTONIC on the other hand is diverging completely when the
system has NTP enabled. A very small frequency adjustment of 12ppm sums
up to ~one second per day.

Thanks,

        tglx