From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 515D131690A for ; Tue, 24 Feb 2026 13:22:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771939367; cv=none; b=psFcXBYbqcy8Pi2GkdzjAARuC84MV5Fkq1+EkZWhaGi/DCqGpd2rUznDA+gl1qrAZHGrDD0cXPD9P6BUZcgRmlYJoxuwGCt8JYNP/mt9AZ71ekHhUvvAINsHP9n8A+QoEfIH9c8zTPZfSuhnccgWL7OEwS/XKpUYAeU2hKruChA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771939367; c=relaxed/simple; bh=SU2cG+wjFKLZ3smT4VORMJ1Pbno6l/2nuVIxBA9lkjQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z1l9axvtRPRngttWXXqizpBcE1B+2RW0nEH72VREqBef468sQhQ7s+wSVEV18DZK5DdHbT3AhoyAS0gfElQKzDik9Qt0qfu4rbw9T8CistmUlYcVDZDRzSHTj+fD1lbpwoypNKgUY4F5U+N0Kx4KeWFkTgyPWgbqSVgnTy/RRxk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TW0wWzGj; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=houDQmju; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TW0wWzGj"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="houDQmju" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771939365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=URimpxj7/K4xVbWm6xD2755atLOFQ76W31SeLfbbhCE=; b=TW0wWzGjTynJGktfRFy8u+2cHOJvzoPcMaA124k5vZLuWUHMFhE2arnCSocjmnbi/l+N1q D+fB5uZ9ogmIrKJIarIg9MXainwIwIgqQ/1K9J81CdY0pON4R1HF2lvgMxdHarIC9GGtR6 jc5/hudn/zM1zJi4Cin8c9M8fKWmN1Y= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-yI_RYQNuMq2qqfSaRgVoaA-1; Tue, 24 Feb 2026 08:22:43 -0500 X-MC-Unique: yI_RYQNuMq2qqfSaRgVoaA-1 X-Mimecast-MFC-AGG-ID: yI_RYQNuMq2qqfSaRgVoaA_1771939363 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-437812b8bb0so3825001f8f.3 for ; Tue, 24 Feb 2026 05:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1771939362; x=1772544162; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=URimpxj7/K4xVbWm6xD2755atLOFQ76W31SeLfbbhCE=; b=houDQmjuBYZEkPkPZ9dmd712hNi7gy9FCbhdO0QoTTmxW9bB6nQV5BbX2lAz2+DZYB PV1KdZWTf0BsqScd2/ZOYgrVF/8xWBOAFfpjvSZXV0FadiTMPqcqTxTcm86U+c4sq4ql pBkeHSqeAy9jUAw8wLWSX13xof/JMHud2eerB8DIUXEedhz/fznxneX7wdOTpVMyXnPj jTBJ/7OPWVmV1NyXe10f2ak3iSXv4gn1I6jAWXLkccfbkfNWBUiONV9eKnQW6JZbjf3h hX48rHZfLngtzQzAo8635ApISfU5Me0RS2yNYenzb2vgnrw3jq/wXzShGBoDEuDE7hfz Nv+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771939362; x=1772544162; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=URimpxj7/K4xVbWm6xD2755atLOFQ76W31SeLfbbhCE=; b=KNmjdW+KUEaxUYWKLm7BP1GDATlDAbORux2mQqOsMWRNsr8hU83wHILI1W0l2eI69D WYB73V4K7FZRctRGEX1GNH/E05Me4JZAv1LjdNDbCTEXHViNEC619awcZSMz2M1lNgRz y19fiSi0ot7TJ2Rct70ItlU2b/v0X0FRhFYOfsdgQ4EjOa1AOrXU2nSDc/3FhJA1OiTq E5BGnhvqWTYthVN2W/93qvRwSwpcC+HtRBvBoHUuWY9ud1OJvPWWKptBPtczIMYaqPOw Nszj0NKvtJxnu+MW8av5hb36B7Q9FzVnNDZt3pEodw82FJAvPpf5IDhjld38f3D+kLqG rZLw== X-Forwarded-Encrypted: i=1; AJvYcCUcwKsR28EwAy12Kxjg0aL2Llem1v7/cakMHZcjI4g6LlEyPrrppdCKeHlVkWVbkBBl/syEQAEmeEenJPo=@vger.kernel.org X-Gm-Message-State: AOJu0Yxwaxs8f9gpYHAnlgADFuCwOkLRjDY3fPR0vY2TT5a0sAQJP694 JsZ03QSt/PcAjTDe8v+Ro2hRq18XRAPARPGaGiSUYQE65Rs6wJVf/vCnAgY3f7sle41GqhIIqDt G0e/lPyvguyhjlu+j7RMOcvrBt9qCDLmor0zUu/67ik9fqM+PR2Gxsy+hj9LNu0nJaTtH7xM04g == X-Gm-Gg: ATEYQzyCxUpgGv/VLCoH7wvJRrTKLjIJpZTknbS1z9W0vgLlvYUypmrCVsYECCq3R65 XDP6SoEtzUMFhgIKme1tU37hH1GcQzo0v4cMptLwUiUiSW1W+mzgWH36LgtNOQQbPmWqlAjAi3m e7CUWHM5iaanC/GWrN8KrWYUYmE89RIhG6JrpRuxTsxhtPz1pR2hHiQ0tLVQ9pXP20zxOkK8d4I D6gCsFFoeLp4th6CTxLyczqsgNZ/kdoJK8TAEXnWQ8HPhjb4P8g2TNjI6AfgDROKtWeX+gnzMSN 8yrYD6EKGlxcXmQmmxLKK6KuZzYmKVlTv58VRlj0kVp4ZP2K5RGu35UkMnC9PcUk+6ICKBSgGPR 4U/exoPh1SG99ncGTcGnL5Pd5XDSHFJDt9upn1vdqy6Luj3n7Dtk= X-Received: by 2002:a05:6000:2583:b0:42f:b9c6:c894 with SMTP id ffacd0b85a97d-4396f187ee3mr24543898f8f.52.1771939362108; Tue, 24 Feb 2026 05:22:42 -0800 (PST) X-Received: by 2002:a05:6000:2583:b0:42f:b9c6:c894 with SMTP id ffacd0b85a97d-4396f187ee3mr24543828f8f.52.1771939361658; Tue, 24 Feb 2026 05:22:41 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.73.19]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43970d54c5csm26948627f8f.38.2026.02.24.05.22.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 05:22:40 -0800 (PST) Date: Tue, 24 Feb 2026 14:22:38 +0100 From: Juri Lelli To: Peter Zijlstra Cc: Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Philip Auld , Gabriele Monaco , linux-kernel@vger.kernel.org, Bruno Goncalves Subject: Re: [PATCH] sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting Message-ID: References: <20260206-upstream-fix-deadline-piboost-b4-v1-1-14043567b89c@redhat.com> <20260207084550.GU1282955@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Peter, On 09/02/26 10:46, Juri Lelli wrote: > On 07/02/26 09:45, Peter Zijlstra wrote: > > On Fri, Feb 06, 2026 at 02:25:52PM +0100, Juri Lelli wrote: > > > > > @@ -284,6 +285,33 @@ static bool check_same_owner(struct task_struct *p) > > > uid_eq(cred->euid, pcred->uid)); > > > } > > > > > > +#ifdef CONFIG_RT_MUTEXES > > > +static void __setscheduler_dl(struct task_struct *p, > > > + struct sched_change_ctx *scope) > > > +{ > > > + struct task_struct *pi_task = rt_mutex_get_top_task(p); > > > + > > > + /* > > > + * In case a former DEADLINE task (either proper or boosted) gets > > > + * setscheduled to a lower priority class, check if it neeeds to > > > + * inherit parameters from a potential pi_task. In that case make > > > + * sure replenishment happens with the next enqueue. > > > + */ > > > + if (!dl_prio(p->normal_prio) && > > > + (pi_task && dl_prio(pi_task->prio))) { > > > + p->dl.pi_se = pi_task->dl.pi_se; > > > + > > > + if (scope && scope->queued) > > > + scope->flags |= ENQUEUE_REPLENISH; > > > + } > > > +} > > > +#else /* !CONFIG_RT_MUTEXES */ > > > +static void __setscheduler_dl(struct task_struct *p, > > > + struct sched_change_ctx *scope) > > > +{ > > > +} > > > +#endif /* !CONFIG_RT_MUTEXES */ > > > + > > > #ifdef CONFIG_UCLAMP_TASK > > > > > > static int uclamp_validate(struct task_struct *p, > > > @@ -657,6 +685,7 @@ int __sched_setscheduler(struct task_struct *p, > > > p->prio = newprio; > > > } > > > __setscheduler_uclamp(p, attr); > > > + __setscheduler_dl(p, scope); > > > > > > if (scope->queued) { > > > /* > > > > > > > Urgh... :-) > > Yeah. > > > So normally it would be __setscheduler_params(), but that funks out > > because !dl_policy() -- after all, we're demoting the boosted task to be > > !DL. > > In this particular case we have a DEADLINE task (holder) that didn't > take the chance of being boosted by another DEADLINE task (donor), > because donor had longer dynamic deadline when rt_mutex_setprio() was > called. So now p->dl.pi_se still points to &p->dl and so enqueue_task_dl > doesn't recognize the holder as boosted and takes the wrong path at the > start. > > > So then we need to fix up things to the effective priority. > > We can use effective priority, right. > > > Should this not be inside the !KEEP_PARAMS thing? Something like so? > > And do it inside !KEEP_PARAMS, indeed. > > > (afaict nothing clears dl_se::pi_se except rt_mutex_setprio() so that > > should still be valid here -- so we don't need to go find it again) > > But, maybe with something like this? I believe we need to make things > right at this point "promoting" the now becoming lower prio class task > to DEADLINE (inheriting from the task it didn't inherit from in the > past). Maybe we can avoid checking pi_task since dl_prio(newprio). And > also move everything in an helper to remove ifdeffery. > > --- > diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c > index 6f10db3646e7f..856df1a22e3ca 100644 > --- a/kernel/sched/syscalls.c > +++ b/kernel/sched/syscalls.c > @@ -655,6 +655,16 @@ int __sched_setscheduler(struct task_struct *p, > __setscheduler_params(p, attr); > p->sched_class = next_class; > p->prio = newprio; > +#ifdef CONFIG_RT_MUTEXES > + if (dl_prio(newprio) && !dl_policy(policy)) { > + struct task_struct *pi_task = rt_mutex_get_top_task(p); > + > + if (pi_task) { > + p->dl.pi_se = pi_task->dl.pi_se; > + scope->flags |= ENQUEUE_REPLENISH; > + } > + } > +#endif > } > __setscheduler_uclamp(p, attr); When you have a minute, can you take a look at the above? Thanks! Juri