linux-kernel - Re: [PATCH] sched/eevdf: Update se->vprot in reweight

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: <44c45e82-25e7-4d70-a46d-fb34e6aacbd6@amd.com>
Date: Fri, 23 Jan 2026 22:09:05 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Peter Zijlstra <peterz@...radead.org>, Vincent Guittot
	<vincent.guittot@...aro.org>
CC: "wangtao (EQ)" <wangtao554@...wei.com>, <mingo@...hat.com>,
	<juri.lelli@...hat.com>, <dietmar.eggemann@....com>, <rostedt@...dmis.org>,
	<bsegall@...gle.com>, <mgorman@...e.de>, <vschneid@...hat.com>,
	<tanghui20@...wei.com>, <zhangqiao22@...wei.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sched/eevdf: Update se->vprot in reweight_entity()

Hello Peter,

On 1/23/2026 9:08 PM, Peter Zijlstra wrote:
> On Wed, Jan 21, 2026 at 06:00:15PM +0100, Vincent Guittot wrote:
> 
>> Why not use update_protect_slice() like when a new task with a shorter
>> slice is added ?
> 
> That seems wrong too...
> 
> I was going over this, and should we not limit set_protect_slice() to
> the first set_next_entity(). That is, AFAICT we'll re-set it on
> sched_change -- which sounds wrong to me.

That makes sense.

> 
> Anyway, I ended up with something like so (should probably be split in
> two patches).
> 
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index eca642295c4b..bab51da3d179 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3790,6 +3790,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  			    unsigned long weight)
>  {
>  	bool curr = cfs_rq->curr == se;
> +	u64 vprot = 0;
>  
>  	if (se->on_rq) {
>  		/* commit outstanding execution time */
> @@ -3797,6 +3798,9 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  		update_entity_lag(cfs_rq, se);
>  		se->deadline -= se->vruntime;
>  		se->rel_deadline = 1;
> +		if (curr && protect_slice(se))
> +			vprot = se->vprot - se->vruntime;
> +
>  		cfs_rq->nr_queued--;
>  		if (!curr)
>  			__dequeue_entity(cfs_rq, se);
> @@ -3812,6 +3816,9 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  	if (se->rel_deadline)
>  		se->deadline = div_s64(se->deadline * se->load.weight, weight);
>  
> +	if (vprot)
> +		vprot = div_s64(vprot * se->load.weight, weight);
> +
>  	update_load_set(&se->load, weight);
>  
>  	do {
> @@ -3823,6 +3830,8 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  	enqueue_load_avg(cfs_rq, se);
>  	if (se->on_rq) {
>  		place_entity(cfs_rq, se, 0);
> +		if (vprot)
> +			se->vprot = se->vruntime + vprot;

Scaling vprot makes sense too. Can there be a problem where "vprot"
turns to zero on scaling (weight > (vprot * se->load.weight)) but we
don't end up updating "se->vprot"?

Probably rare but a higher weight implies it might take a tad bit
longer to hit that old "vprot" but since we are losing the precision,
can the pending "se->vprot" be big enough to cause any issue?

Since we are looking at these bits, can you also please take a look at
https://lore.kernel.org/lkml/20251226001731.3730586-1-quzicheng@huawei.com/
which I feel might be a genuine issue when we are reweight the curr's
vruntime.

>  		update_load_add(&cfs_rq->load, se->load.weight);
>  		if (!curr)
>  			__enqueue_entity(cfs_rq, se);

-- 
Thanks and Regards,
Prateek