linux-kernel - Re: [RFC PATCH] sched/core: Stash task priority after dequeue and put_prev_task() in sched_change

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: <693c35a3-a83c-4ed8-ad5d-5ff4ab7b40c6@amd.com>
Date: Wed, 7 Jan 2026 11:01:11 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>, Sebastian Andrzej Siewior
	<bigeasy@...utronix.de>, Clark Williams <clrkwllms@...nel.org>,
	<linux-kernel@...r.kernel.org>, <linux-rt-devel@...ts.linux.dev>, "Dietmar
 Eggemann" <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, "Valentin
 Schneider" <vschneid@...hat.com>, Tejun Heo <tj@...nel.org>, "Gautham R.
 Shenoy" <gautham.shenoy@....com>
Subject: Re: [RFC PATCH] sched/core: Stash task priority after dequeue and
 put_prev_task() in sched_change_begin()

Hello Peter,

On 1/6/2026 4:11 PM, Peter Zijlstra wrote:
> On Tue, Jan 06, 2026 at 07:52:39AM +0000, K Prateek Nayak wrote:
>> When running amd-pstate driver on a PREEMPT_RT kernel on a shared memory
>> system (Zen3 and prior), the following splat was observed from
>> triggering the WARN_ON_ONCE() in rq_pin_lock():
>>
>>     ------------[ cut here ]------------
>>     WARNING: kernel/sched/sched.h:1807 at __schedule+0x122/0x17c0, CPU#8: swapper/0/1
> 
> Can you enable CONFIG_DEBUG_BUGVERBOSE_DETAILED?

Ack! I didn't know this was the config that printed the condition for
the warn on. I'll make sure to enable it henceforth.

[..snip..]

>> Since the dequeue on a deadline task can push its deadline, stash the
>> task prio towards the end of sched_change_begin().
>>
>> The modification to priority within the sched_change guard's scope will
>> still be considered as sched_change_end() will supply the priority
>> stashed at the end of constructor's execution as the old priority to
>> sched_class->prio_changed().
>>
> 
> Would not something like so make more sense?
> 
> ---
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 80c9559a3e30..60e0c25aae78 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -3306,6 +3306,8 @@ static void switched_to_dl(struct rq *rq, struct task_struct *p)
>  
>  static u64 get_prio_dl(struct rq *rq, struct task_struct *p)
>  {
> +	if (task_current_donor(rq, p))
> +		update_curr_dl(rq);
>  	return p->dl.deadline;
>  }
>  

Yup this makes sense too! Feel free to add a small note like:

Catch up the deadline before returning it from get_prio() for the
current donor. This ensures the sched_change guard caches the latest
value and doesn't mistake the subsequent dequeue to have changed the
task's priority.

and include:

Reviewed-and-tested-by: K Prateek Nayak <kprateek.nayak@....com>

-- 
Thanks and Regards,
Prateek