linux-kernel - Re: [PATCH 5/5] rv: Add rts 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250801075810._Ng7G1QT@linutronix.de>
Date: Fri, 1 Aug 2025 09:58:10 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>
Subject: Re: [PATCH 5/5] rv: Add rts monitor

On Thu, Jul 31, 2025 at 09:47:10AM +0200, Gabriele Monaco wrote:
> On Wed, 2025-07-30 at 14:45 +0200, Nam Cao wrote:
> > Add "real-time scheduling" monitor, which validates that SCHED_RR and
> > SCHED_FIFO tasks are scheduled before tasks with normal and
> > extensible
> > scheduling policies
> > 
> 
> Looks a very interesting monitor!
> A few questions:
> 
> I assume this works with rt-throttle because it implies a dequeue,
> right?
> And you probably won't see that without explicit tracepoints..

It does work properly with rt-throttling:
	root@...low:~# ./rt-loop
	[   74.357730] sched: RT throttling activated
	[   74.357745] rv: rts: 0: violation detected

Looking at rt-throlling code, it does not dequeue tasks, only does
	rt_rq->rt_throttled = 1;
	rt_rq->rt_queued = 0;

so we are fine.

> > +	/*
> > +	 * This may not be accurate, there may be enqueued RT tasks.
> > But
> > that's
> > +	 * okay, the worst we get is a false negative. It will be
> > accurate
> > as
> > +	 * soon as the CPU no longer has any queued RT task.
> > +	 */
> > +	ltl_atom_set(mon, LTL_RT_TASK_ENQUEUED, false);
> > 
> 
> As far as I understand here the monitor would just miss RT tasks
> already running but would perfectly enforce the ones starting after
> initialisation, right?

Not exactly. What could happen is that:

 - RT task A already running

 - monitor enabled. The monitor isn't aware of task A, therefore it allows
   sched_switch to switch to non-RT task.

 - RT task B is queued. The monitor now knows at least one RT task is
   enqueued, so it disallows sched_switch to switch to non-RT.

 - RT task A is dequeued. However, the monitor does not differentiate task
   A and task B, therefore I thinks the only enqueued RT task is now gone.

 - So now we have task B started after the monitor, but the monitor does
   not check it.

The monitor will become accurate once the CPU has no enqueued RT task,
which should happen quite quickly on a sane setup where RT tasks do not
monopoly the CPU.

The monitor could be changed to be accurate from the get-go, by looking at
how many enqueued RT tasks are present. I *think* rt_rq->rt_nr_running
works. But I think the current implementation is fine, so not worth
thinking too much about it.

> > +RULE = always (RT_TASK_ENQUEUED imply SCHEDULE_RT_NEXT)
> > +
> > +SCHEDULE_RT_NEXT = (not SCHED_SWITCH) until (SCHED_SWITCH_RT or
> > EXCEPTIONS)
> > +
> > +EXCEPTIONS = SCHED_SWITCH_DL or not RT_TASK_ENQUEUED
> 
> This monitor allows non-RT tasks to run indefinitely before the switch,
> only when it happens, RT must run, right?

Yes.

> Not sure you can do much about it though. (without falling into the
> need resched rabbithole I was trying to untangle)

I would need to look into scheduler code, maybe we could check that the
next scheduler tick implies a sched_switch. Another day.

Nam