Re: [RFC PATCH v2] Documentation/rv: Explain epoll and aborted sleeps

Gabriele Monaco <[email protected]> Tue, 04 Aug 2026 12:45:16 +0200
Newsgroups gmane.linux.kernel,gmane.linux.documentation
Message-ID <[email protected]>
On Wed, 2026-07-29 at 16:11 +0800, Chao Liu wrote:
> epoll_wait() is a valid sleeping reason for real-time tasks because it
> uses PI-aware locking, but the rtapp sleep monitor documentation only
> discusses clock_nanosleep() and futexes. Document it.
>=20
> ABORT_SLEEP represents a task restoring TASK_RUNNING before entering
> the scheduler. Since the task does not actually block, it becomes
> runnable again without a wakeup sequence unsafe for real-time. Document
> this behavior.
>=20

Looks good, thanks! Please next time you send a patch, even if it's an RFC,=
 put
the extra comments after the --- . This way I can pull it directly without
changing the commit message because git am ignores everything after the ---=
 .
Also, no big deal, but for simple patches like this one, and even after get=
ting
comments, there's no need to mark as RFC.

Reviewed-by: Gabriele Monaco <[email protected]>

I'd appreciate an ack from Nam, then I might be able to squeeze this before=
 the
merge window together with the last fixes.

Thanks,
Gabriele

> This RFC is based on Nam Cao's pending "rv: rtapp monitor update" v2
> series:
>=20
> https://lore.kernel.org/r/[email protected]
>=20
> Signed-off-by: Chao Liu <[email protected]>
> ---
> Changes in v2:
> - Explain why epoll_wait() is RT-safe in terms of PI-aware locking.
> - Explain that ABORT_SLEEP does not require an RT-unsafe wakeup sequence.
> - Update the commit message accordingly.
>=20
> Link to v1:
> https://lore.kernel.org/linux-trace-kernel/20260722045706.85633-1-chao.li=
[email protected]/
>=20
> =C2=A0Documentation/trace/rv/monitor_rtapp.rst | 6 ++++++
> =C2=A01 file changed, 6 insertions(+)
>=20
> diff --git a/Documentation/trace/rv/monitor_rtapp.rst
> b/Documentation/trace/rv/monitor_rtapp.rst
> index 238b59395ff5..b95994ade14a 100644
> --- a/Documentation/trace/rv/monitor_rtapp.rst
> +++ b/Documentation/trace/rv/monitor_rtapp.rst
> @@ -67,6 +67,8 @@ thread to sleep for one of the following reasons:
> =C2=A0=C2=A0=C2=A0=C2=A0 variables as safe for real-time. As an alternati=
ve, the librtpi library
> =C2=A0=C2=A0=C2=A0=C2=A0 exists to provide a conditional variable impleme=
ntation that is correct
> for
> =C2=A0=C2=A0=C2=A0=C2=A0 real-time applications in Linux.
> +=C2=A0 - Real-time thread waiting for events using `epoll_wait`, which i=
s a
> +=C2=A0=C2=A0=C2=A0 real-time-safe syscall for sleeping as it uses PI-awa=
re locking.
> =C2=A0
> =C2=A0Beside the reason for sleeping, the eventual waker should also be
> =C2=A0real-time-safe. Namely, one of:
> @@ -114,6 +116,10 @@ The monitor's specification is::
> =C2=A0=C2=A0 ALLOWLIST =3D BLOCK_ON_RT_MUTEX
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or FUT=
EX_LOCK_PI
> =C2=A0
> +`ABORT_SLEEP` represents a task restoring its state to `TASK_RUNNING` be=
fore
> +entering the scheduler. In this case, the task does not actually block, =
so
> the
> +task is back to runnable without any wakeup sequence unsafe for real-tim=
e.
> +
> =C2=A0Beside the scenarios described above, this specification also defin=
es an
> allow list
> =C2=A0to handle some special cases:
> =C2=A0
>=20
> base-commit: 248951ddc14de84de3910f9b13f51491a8cd91df
> prerequisite-patch-id: d8b6c952a954662852e6b0684e0a3386eaab7f41
> prerequisite-patch-id: 940f7637aeabe4ba15a09c048c6f48138406f332
> prerequisite-patch-id: b99812692691f76d825778e01a2e771e058febd6
> prerequisite-patch-id: 512c300dce2cb74ac9cc007f9234aa507ef5c008