[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r1wzk2p5.fsf@nanos.tec.linutronix.de>
Date: Tue, 07 Apr 2020 12:30:46 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Andrei Vagin <avagin@...il.com>,
"Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>
Cc: Andrei Vagin <avagin@...nvz.org>, Dmitry Safonov <dima@...sta.com>,
linux-man <linux-man@...r.kernel.org>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Linux API <linux-api@...r.kernel.org>,
Containers <containers@...ts.linux-foundation.org>,
Dmitry Safonov <0x7f454c46@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
Cyrill Gorcunov <gorcunov@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Andy Lutomirski <luto@...nel.org>,
Adrian Reber <adrian@...as.de>
Subject: Re: RFC: time_namespaces(7) manual page
Andrei Vagin <avagin@...il.com> writes:
> On Sat, Apr 04, 2020 at 01:08:50PM +0200, Michael Kerrisk (man-pages) wrote:
>> /proc/PID/timens_offsets
>> Associated with each time namespace are offsets, expressed with
>> respect to the initial time namespace, that define the values of
>> the monotonic and boot clocks in that namespace. These offsets
>> are exposed via the file /proc/PID/timens_offsets. Within this
>> file, the offsets are expressed as lines consisting of three
>> space-delimited fields:
>>
>> <clock-id> <offset-secs> <offset-nanosecs>
>>
>> The clock-id identifies the clock whose offsets are being shown.
>> This field is either 1, for CLOCK_MONOTONIC, or 7, for CLOCK_BOOT‐
>> TIME. The remaining fields express the offset (seconds plus
>> nanoseconds) for the clock in this time namespace. These offsets
>> are expressed relative to the clock values in the initial time
>> namespace. In the initial time namespace, the contents of this
>> file are as follows:
>
> I think we can mention that offset-secs can be negative, but
> offset-nanosleep has to be 0 or positive.
I assume you meant offset-nanosecs :)
That aside, there are also limitations in place.
1) Negative offsets which would offset time into negative space are
rejected, i.e. its enforced that
now(CLOCK) + offset[CLOCK] >= 0
This is necessary as the kernel expects and also enforces that time
cannot be negative.
2) Positive offsets which would offset time above KTTIME_SEC_MAX / 2 are
rejected, i.e. it's enforced that
now(CLOCK) + offset[CLOCK] <= KTIME_SEC_MAX / 2
That is done to prevent that clocks wrap around if the offset would
bring it close enough to the wrap around point.
The cutoff value is a pretty arbitrary choice (~146 years). So to
hit this you'd need a system which has an uptime of > 146 years,
which is pretty much unrealistic.
Thanks,
tglx
Powered by blists - more mailing lists