Re: [PATCH v2] docs: timers: hrtimers: clarify expiry modes and ktimersd on PREEMPT_RT

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Reference to non-existent API `hrtimer_setup_sleeper()` in documentation.
--

--- Patch [1]: [PATCH v2] docs: timers: hrtimers: clarify expiry modes and ktimersd on PREEMPT_RT ---
commit 2dc8d2cd0774356027c94f2b3b606b15bca92ef3
Author: Liang Hao <[email protected]>

docs: timers: hrtimers: clarify expiry modes and ktimersd on PREEMPT_RT

This commit documents the PREEMPT_RT expiry-mode semantics for timers not
explicitly marked HRTIMER_MODE_HARD, explaining how they default to softirq
expiry on the ktimers thread. It also clarifies priority inheritance rules
and sleeper exceptions for RT/DL-armed timers.

> diff --git a/Documentation/timers/hrtimers.rst b/Documentation/timers/hrtimers.rst
> --- a/Documentation/timers/hrtimers.rst
> +++ b/Documentation/timers/hrtimers.rst

[ ... ]

> +Priority inheritance on PREEMPT_RT is used for the cancel handshake,
> +not for the arming path; see the "Spin until ready" section of the same
> +document.
> +
> +``hrtimer_setup_sleeper()`` (used by ``clock_nanosleep()`` and similar)

[Severity: Low]
This isn't a bug, but should this refer to hrtimer_setup_sleeper_on_stack()
instead? The hrtimer_setup_sleeper() API does not appear to exist in the
source tree, as the exported API for this functionality is
hrtimer_setup_sleeper_on_stack(), which internally calls
__hrtimer_setup_sleeper().

> +is an exception: when armed by an RT or DEADLINE task it is marked
> +``HRTIMER_MODE_HARD``, so the wakeup runs in hardirq context and does
> +not go through ``ktimers/%u``.
> +
> +If callback work must run at the owning task's RT priority, either
> +mark the timer ``HRTIMER_MODE_HARD`` (and keep the callback
> +hardirq-safe) or wake a dedicated kthread from the callback.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1