linux-kernel - Re: [PATCH v2 21/22] rv: Add documentation for rtapp monitor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250416043727.4c1KgDrO@linutronix.de>
Date: Wed, 16 Apr 2025 06:37:27 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
	john.ogness@...utronix.de
Subject: Re: [PATCH v2 21/22] rv: Add documentation for rtapp monitor

On Tue, Apr 15, 2025 at 03:12:23PM +0200, Gabriele Monaco wrote:
> On Fri, 2025-04-11 at 09:37 +0200, Nam Cao wrote:
> > +  - `RT_SLEEP_WHITELIST`: to handle known false positives with
> > kernel tasks.
> 
> Is this what you call ALLOWLIST?

Yes. A colleague already poked me off-list about this error :(

> Just out of curiosity, normal kernel threads are not forced to follow a
> VALID_SLEEP_REASON but need RT_FRIENDLY_WAKE, how are tasks like RCU
> and migration not following this?

Because that's how RCU and migration works, they are intended to be woken
by anything.

It is also possible that people deliberately design their userspace
real-time threads to be woken by non-real-time threads. For example,
pipewire has a non-real-time thread waking a real-time thread to do some
non-critical work. That's still okayish from real-time perspective (but it
is better if the non-real-time thread just does the work itself).

This monitor's warning is not exactly a "here's a bug, fix it". But more
like "something seems really wrong here, please investigate". People can
decide whether this particular suspicious instance is acceptable for their
case.

The initial implementation of the monitor didn't have this allowlist. And
we had a bunch of warnings on the rcu_preempt and migration/ threads. We
decided that due to how rcu and migration works, these warnings are okay.

> The monitors are not designed for deadline tasks, any plan to extend to
> those too?

I haven't thought much about deadline tasks. But it could be extended by
changing "RT" into "RT or DL", if needed.

> Other than this, nice explanation and monitors, thanks.
> 
> Reviewed-by: Gabriele Monaco <gmonaco@...hat.com>

Thanks so much for the review!
Nam