linux.git/kernel/time/vsyscall.c, branch v6.12.80

vdso: Add vdso_data:: Max_cycles

2024-04-08T13:03:07+00:00

Add vdso_data::max_cycles in preparation to use it to detect potential
multiplication overflow.

Suggested-by: Thomas Gleixner 
Signed-off-by: Adrian Hunter 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20240325064023.2997-7-adrian.hunter@intel.com

timekeeping, clocksource: Fix various typos in comments

2021-03-22T22:06:48+00:00

Fix ~56 single-word typos in timekeeping & clocksource code comments.

Signed-off-by: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Stephen Boyd 
Cc: Daniel Lezcano 
Cc: linux-kernel@vger.kernel.org

timekeeping/vsyscall: Provide vdso_update_begin/end()

2020-08-06T08:57:30+00:00

Architectures can have the requirement to add additional architecture
specific data to the VDSO data page which needs to be updated independent
of the timekeeper updates.

To protect these updates vs. concurrent readers and a conflicting update
through timekeeping, provide helper functions to make such updates safe.

vdso_update_begin() takes the timekeeper_lock to protect against a
potential update from timekeeper code and increments the VDSO sequence
count to signal data inconsistency to concurrent readers. vdso_update_end()
makes the sequence count even again to signal data consistency and drops
the timekeeper lock.

[ Sven: Add interrupt disable handling to the functions ]

Signed-off-by: Thomas Gleixner 
Signed-off-by: Sven Schnelle 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20200804150124.41692-3-svens@linux.ibm.com

lib/vdso: Avoid highres update if clocksource is not VDSO capable

2020-02-17T19:12:17+00:00

If the current clocksource is not VDSO capable there is no point in
updating the high resolution parts of the VDSO data.

Replace the architecture specific check with a check for a VDSO capable
clocksource and skip the update if there is none.

Signed-off-by: Thomas Gleixner 
Tested-by: Vincenzo Frascino 
Reviewed-by: Vincenzo Frascino 
Link: https://lkml.kernel.org/r/20200207124403.563379423@linutronix.de

lib/vdso: Cleanup clock mode storage leftovers

2020-02-17T19:12:17+00:00

Now that all architectures are converted to use the generic storage the
helpers and conditionals can be removed.

Signed-off-by: Thomas Gleixner 
Tested-by: Vincenzo Frascino 
Reviewed-by: Vincenzo Frascino 
Link: https://lkml.kernel.org/r/20200207124403.470699892@linutronix.de

clocksource: Add common vdso clock mode storage

2020-02-17T13:40:23+00:00

All architectures which use the generic VDSO code have their own storage
for the VDSO clock mode. That's pointless and just requires duplicate code.

Provide generic storage for it. The new Kconfig symbol is intermediate and
will be removed once all architectures are converted over.

Signed-off-by: Thomas Gleixner 
Tested-by: Vincenzo Frascino 
Reviewed-by: Vincenzo Frascino 
Link: https://lkml.kernel.org/r/20200207124403.028046322@linutronix.de

lib/vdso: Update coarse timekeeper unconditionally

2020-01-17T14:53:50+00:00

The low resolution parts of the VDSO, i.e.:

  clock_gettime(CLOCK_*_COARSE), clock_getres(), time()

can be used even if there is no VDSO capable clocksource.

But if an architecture opts out of the VDSO data update then this
information becomes stale. This affects ARM when there is no architected
timer available. The lack of update causes userspace to use stale data
forever.

Make the update of the low resolution parts unconditional and only skip
the update of the high resolution parts if the architecture requests it.

Fixes: 44f57d788e7d ("timekeeping: Provide a generic update_vsyscall() implementation")
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20200114185946.765577901@linutronix.de

lib/vdso: Make __arch_update_vdso_data() logic understandable

2020-01-17T14:53:50+00:00

The function name suggests that this is a boolean checking whether the
architecture asks for an update of the VDSO data, but it works the other
way round. To spare further confusion invert the logic.

Fixes: 44f57d788e7d ("timekeeping: Provide a generic update_vsyscall() implementation")
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20200114185946.656652824@linutronix.de

timekeeping/vsyscall: Update VDSO data unconditionally

2019-11-04T22:02:53+00:00

The update of the VDSO data is depending on __arch_use_vsyscall() returning
True. This is a leftover from the attempt to map the features of various
architectures 1:1 into generic code.

The usage of __arch_use_vsyscall() in the actual vsyscall implementations
got dropped and replaced by the requirement for the architecture code to
return U64_MAX if the global clocksource is not usable in the VDSO.

But the __arch_use_vsyscall() check in the update code stayed which causes
the VDSO data to be stale or invalid when an architecture actually
implements that function and returns False when the current clocksource is
not usable in the VDSO.

As a consequence the VDSO implementations of clock_getres(), time(),
clock_gettime(CLOCK_.*_COARSE) operate on invalid data and return bogus
information.

Remove the __arch_use_vsyscall() check from the VDSO update function and
update the VDSO data unconditionally.

[ tglx: Massaged changelog and removed the now useless implementations in
  	asm-generic/ARM64/MIPS ]

Fixes: 44f57d788e7deecb50 ("timekeeping: Provide a generic update_vsyscall() implementation")
Signed-off-by: Huacai Chen 
Signed-off-by: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Vincenzo Frascino 
Cc: Arnd Bergmann 
Cc: Paul Burton 
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1571887709-11447-1-git-send-email-chenhc@lemote.com

timekeeping/vsyscall: Prevent math overflow in BOOTTIME update

2019-08-23T00:12:11+00:00

The VDSO update for CLOCK_BOOTTIME has a overflow issue as it shifts the
nanoseconds based boot time offset left by the clocksource shift. That
overflows once the boot time offset becomes large enough. As a consequence
CLOCK_BOOTTIME in the VDSO becomes a random number causing applications to
misbehave.

Fix it by storing a timespec64 representation of the offset when boot time
is adjusted and add that to the MONOTONIC base time value in the vdso data
page. Using the timespec64 representation avoids a 64bit division in the
update code.

Fixes: 44f57d788e7d ("timekeeping: Provide a generic update_vsyscall() implementation")
Reported-by: Chris Clayton 
Signed-off-by: Thomas Gleixner 
Tested-by: Chris Clayton 
Tested-by: Vincenzo Frascino 
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1908221257580.1983@nanos.tec.linutronix.de