linux-kernel - Re: [PATCH RFC] sched: Disable DL server if sysctl_sched_rt

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: <20250304150632.3fde716c@gandalf.local.home>
Date: Tue, 4 Mar 2025 15:06:32 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: 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 RFC] sched: Disable DL server if sysctl_sched_rt_runtime
 is -1

On Tue,  4 Mar 2025 15:01:16 -0500
Joel Fernandes <joelagnelf@...dia.com> wrote:

> Currently, RCU boost testing in rcutorture is broken because it relies on
> having RT throttling disabled. This means the test will always pass (or
> rarely fail). This occurs because recently, RT throttling was replaced
> by DL server which boosts CFS tasks even when rcutorture tried to
> disable throttling (see rcu_torture_disable_rt_throttle()).
> 
> Therefore this patch prevents DL server from starting when RC torture
> sets the sysctl_sched_rt_runtime to -1.
> 
> With this patch, boosting in TREE09 fails more than 50% of boost attempts
> making the test more useful.
> 
> Also add a check of this to task_non_contending() because otherwise it
> throws a warning (in the case when DL server was already started before
> rcutorture started).
> 

Hmm, I wonder if dl_server caused a regression. That is, disabling rt
throttling should allow RT tasks to starve anything it wants. And some RT
applications rely on this.

Should this include a Fixes and Cc stable?

-- Steve


> Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>
> ---
>  kernel/sched/deadline.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 38e4537790af..09c5139a3183 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -448,7 +448,7 @@ static void task_non_contending(struct sched_dl_entity *dl_se)
>  	if (dl_entity_is_special(dl_se))
>  		return;
>  
> -	WARN_ON(dl_se->dl_non_contending);
> +	WARN_ON(dl_se->dl_non_contending && rt_bandwidth_enabled());
>  
>  	zerolag_time = dl_se->deadline -
>  		 div64_long((dl_se->runtime * dl_se->dl_period),
> @@ -1648,6 +1648,13 @@ void dl_server_start(struct sched_dl_entity *dl_se)
>  {
>  	struct rq *rq = dl_se->rq;
>  
> +	/*
> +	 * Prevent dl_server from starting if RT bandwidth is not enabled.
> +	 * This is used by test code to test RCU boosting.
> +	 */
> +	if (!rt_bandwidth_enabled())
> +		return;
> +
>  	/*
>  	 * XXX: the apply do not work fine at the init phase for the
>  	 * fair server because things are not yet set. We need to improve