linux.git/kernel/time/sched_clock.c, branch v6.18.21

time/sched_clock: Use ACCESS_PRIVATE() to evaluate hrtimer::function

2026-02-26T22:59:02+00:00

[ Upstream commit 3db5306b0bd562ac0fe7eddad26c60ebb6f5fdd4 ]

This dereference of sched_clock_timer::function was missed when the
hrtimer callback function pointer was marked private.

Fixes: 04257da0c99c ("hrtimers: Make callback function pointer private")
Reported-by: kernel test robot 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/875x95jw7q.ffs@tglx
Closes: https://lore.kernel.org/oe-kbuild-all/202601131713.KsxhXQ0M-lkp@intel.com/
Signed-off-by: Sasha Levin

time/sched_clock: Export symbol for sched_clock register function

2025-09-23T08:52:31+00:00

The timer drivers could be converted into modules. The different
functions to register the clocksource or the clockevent are already
exporting their symbols for modules but the sched_clock_register()
function is missing.

Export the symbols so the drivers using this function can be converted
into modules.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Carlos Llamas 
Reviewed-by: Will McVicker 
Acked-by: John Stultz 
Link: https://lore.kernel.org/r/20250602151853.1942521-8-daniel.lezcano@linaro.org

time: Switch to hrtimer_setup()

2025-02-18T09:32:33+00:00

hrtimer_setup() takes the callback function pointer as argument and
initializes the timer completely.

Replace hrtimer_init() and the open coded initialization of
hrtimer::function with the new setup mechanism.

Signed-off-by: Nam Cao 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/170bb691a0d59917c8268a98c80b607128fc9f7f.1738746821.git.namcao@linutronix.de

seqlock, treewide: Switch to non-raw seqcount_latch interface

2024-11-05T11:55:35+00:00

Switch all instrumentable users of the seqcount_latch interface over to
the non-raw interface.

Co-developed-by: "Peter Zijlstra (Intel)" 
Signed-off-by: "Peter Zijlstra (Intel)" 
Signed-off-by: Marco Elver 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20241104161910.780003-5-elver@google.com

time/sched_clock: Broaden sched_clock()'s instrumentation coverage

2024-11-05T11:55:35+00:00

Most of sched_clock()'s implementation is ineligible for instrumentation
due to relying on sched_clock_noinstr().

Split the implementation off into an __always_inline function
__sched_clock(), which is then used by the noinstr and instrumentable
version, to allow more of sched_clock() to be covered by various
instrumentation.

This will allow instrumentation with the various sanitizers (KASAN,
KCSAN, KMSAN, UBSAN). For KCSAN, we know that raw seqcount_latch usage
without annotations will result in false positive reports: tell it that
all of __sched_clock() is "atomic" for the latch reader; later changes
in this series will take care of the writers.

Co-developed-by: "Peter Zijlstra (Intel)" 
Signed-off-by: "Peter Zijlstra (Intel)" 
Signed-off-by: Marco Elver 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20241104161910.780003-3-elver@google.com

time/sched_clock: Swap update_clock_read_data() latch writes

2024-11-05T11:55:34+00:00

Swap the writes to the odd and even copies to make the writer critical
section look like all other seqcount_latch writers.

Signed-off-by: Marco Elver 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20241104161910.780003-2-elver@google.com

time/sched_clock: Provide sched_clock_noinstr()

2023-06-05T19:11:04+00:00

With the intent to provide local_clock_noinstr(), a variant of
local_clock() that's safe to be called from noinstr code (with the
assumption that any such code will already be non-preemptible),
prepare for things by providing a noinstr sched_clock_noinstr() function.

Specifically, preempt_enable_*() calls out to schedule(), which upsets
noinstr validation efforts.

As such, pull out the preempt_{dis,en}able_notrace() requirements from
the sched_clock_read() implementations by explicitly providing it in
the sched_clock() function.

This further requires said sched_clock_read() functions to be noinstr
themselves, for ARCH_WANTS_NO_INSTR users. See the next few patches.

Signed-off-by: Peter Zijlstra (Intel) 
Tested-by: Michael Kelley   # Hyper-V
Link: https://lore.kernel.org/r/20230519102715.302350330@infradead.org

seqlock/latch: Provide raw_read_seqcount_latch_retry()

2023-06-05T19:11:03+00:00

The read side of seqcount_latch consists of:

  do {
    seq = raw_read_seqcount_latch(&latch->seq);
    ...
  } while (read_seqcount_latch_retry(&latch->seq, seq));

which is asymmetric in the raw_ department, and sure enough,
read_seqcount_latch_retry() includes (explicit) instrumentation where
raw_read_seqcount_latch() does not.

This inconsistency becomes a problem when trying to use it from
noinstr code. As such, fix it by renaming and re-implementing
raw_read_seqcount_latch_retry() without the instrumentation.

Specifically the instrumentation in question is kcsan_atomic_next(0)
in do___read_seqcount_retry(). Loosing this annotation is not a
problem because raw_read_seqcount_latch() does not pass through
kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX).

Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Petr Mladek 
Tested-by: Michael Kelley   # Hyper-V
Link: https://lore.kernel.org/r/20230519102715.233598176@infradead.org

time/sched_clock: Fix formatting of frequency reporting code

2022-05-02T12:29:04+00:00

Use flat rather than nested indentation for chained else/if clauses as 
per coding-style.rst:

	if (x == y) {
		..
	} else if (x > y) {
		...
	} else {
		....
	}

This also improves readability.

Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204240148220.9383@angie.orcam.me.uk

time/sched_clock: Use Hz as the unit for clock rate reporting below 4kHz

2022-05-02T12:29:04+00:00

The kernel uses kHz as the unit for clock rates reported between 1MHz
(inclusive) and 4MHz (exclusive), e.g.:

 sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns

This reduces the amount of data lost due to rounding, but hasn't been
replicated for the kHz range when support was added for proper reporting of
sub-kHz clock rates.  Take the same approach for rates between 1kHz
(inclusive) and 4kHz (exclusive), which makes it consistent.

Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204240106380.9383@angie.orcam.me.uk