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.129.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 85F1617D2 for ; Mon, 9 Feb 2026 09:46:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770630384; cv=none; b=uMQMJdO1kHtFaFOWg9ku1eNXhzV11DSH2ZPHt69UCSNhQUmBBdke8lWXR7yYiCyct2+7/AKChC5LCGcJodNkrzAyna1wDaeStyf94Sd/ru2GHcgqnxZIQ/nAdZY32HIy44buTtMK0OvnnVaWxoEFiACv06MhpU0R32bNmTQUKBc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770630384; c=relaxed/simple; bh=Zx7IWTH2Z0YmICapM99UU6sW0mhiEhxitdhHk7ZJ0yU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iMXx67dGpaAaG+m1BJeA9U0MoIbiM7MJnSEDpNLLnrZJm9nCq9QIsvQ4jjlvrf8Y005xowhGg78j1vDBLu//ez+mCKyGYDZRiVe6Nbdp/4kFpoQzOldBAm96R8vbCDIaUWkcvODrWRuz9PNbYTnI2Ta9mS4tUguWwhlsat3SfAY= 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=PQEDmH5U; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Vffxdtjk; arc=none smtp.client-ip=170.10.129.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="PQEDmH5U"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Vffxdtjk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770630383; 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=gfJ0kmqHchXM3HXilIXhkz84oE593BCPlH6a+xQRgZU=; b=PQEDmH5UNznW3pyyqbo/rR+yzLZgEs1Kwy8eB0k5F4KMVmxw/HwGEY95rdhSEPgMhPFlAP yodh+BqhvxTeQi8ZLck2Z+XXdKJut8qWnUIqjyzzHcfJus/3MR4j2yvAa6gF5dbYyx8jJP SVFxW742GyGNEi/Hoo3qgdjoEjSmuAo= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-359-g5J2G1T7OT6d0lx1iT1N8A-1; Mon, 09 Feb 2026 04:46:22 -0500 X-MC-Unique: g5J2G1T7OT6d0lx1iT1N8A-1 X-Mimecast-MFC-AGG-ID: g5J2G1T7OT6d0lx1iT1N8A_1770630381 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-4376ecafb7fso387710f8f.2 for ; Mon, 09 Feb 2026 01:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770630381; x=1771235181; 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=gfJ0kmqHchXM3HXilIXhkz84oE593BCPlH6a+xQRgZU=; b=VffxdtjkKsD2MhsF+zJaMshjXnPEVszqSDsl3xeYoupA5uN8adKNYOjD9ZjO4IhKZq 2qD8P6agEmpauDo1yOdiKG7ltfRuU0X9wJdIbs8xer7CukY6KyW1R2DnHm2NVZR+WUQ/ 2MGX7Tu8zlFP9j7lHmFdM6U8adHXigztQkXRjvKU/dBXNaQv5Gr2UjHm8GRZJykIvUhJ DvaaXY3JrDQ59kiwgphZevJeLYvNbvYfElXsr/5cMivIYY+8sS3j5Qv6JSqSLnX2XWdf /RtEwysmXNzZXhuEF2AEam/tJWxk4svVqfpfxSP1V0n/9ASBZ7FKnOinM6106aTQ0b9h VIBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770630381; x=1771235181; 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=gfJ0kmqHchXM3HXilIXhkz84oE593BCPlH6a+xQRgZU=; b=CVbyB1gVNh150l1ovoyQrrMcMDAslYN4w5LxQAgkZYaG4RxGzOrohBWdpGdeb2VnVd /J3FA+zt9pjvR9aKCVj7DxVI1bTo0fhmu5yIiklbMm3zTuSDCn8emhJ7zD7kxUYy/dKW 0TxnHPueHE3l0H5qOndauMo23HTQdMMfI92R8ziPM0PELOA+MLvuTRMLQae2bZyyFPE/ 1Q7Aac3PorE1Qduu9inXAse4FurmaiVFrCu7F0buhZNXtvnXJafbBFXR4UQreeprLmNo XV3r60ZDAUh8fWqW3CwcuxQWC/b61YvT7yDK/K9HKgIv4+ZKYFcuNfmGBJdIoIuPkxhC 8reg== X-Forwarded-Encrypted: i=1; AJvYcCU5Q4FKmMiyFn0okFCLyLp8T0irF0nz/T56GiuiLLjzlf6XgvX/byUfnlPWrpAZ/v5mjg4X/rLtUZ7EKqs=@vger.kernel.org X-Gm-Message-State: AOJu0YxGDniYXvp3fkWEeb6MQNUXWDOM+quS7VZAne0YmeXByvdnRSgx b56JCq9uoLo3Ut30fGaumtuw4Yh6lEwGxn+sMNiUvIm2R9eFJq7+pxRTG9QQ69lht/HwiiaTUVX kiSEYbMVmFa7ZOw99gh0KPBRMur66c+HOq+eRTjiGwLhJEgCgmG5qyfZ+9pXVSViziQ== X-Gm-Gg: AZuq6aLwEgLyLGotrMP5jaD1GwXyJ5AGR5pxsf6jqtL2dQDo16WzG3Z6E6bWwqUY3IY 6lC2zCFC64EaCRmprKY+p1QV3Wsu0KLVgA/ZqGxX/iNpWGSbL1UuxKecgzRZCCpNAPu8YGTMX24 dBvYYCmtlQaRe8RCLmMtD0BhwHSXVb1oCMMNgH1CHWvlvDSq3+TN1Orc8cNEKh4ANu0MnLFBttx xYJsHl5T3RtK1BgczRmBP1Fbzg6NTa4eevvRXEqtn8H7XdwjFexGZwwPSDBNz2IRzs/r15DqlPC xbMwjLIqH8X+Z6wkBuUx34v2WUaKX1ZX7JDvqYX8ZvNojq7ylBR/kcCcuIKZAEg5JFegKbSzc1N 4KCIGMVSoYV+kNpEpU1ABBiuGeAV5n+JqFWMAnnKQ X-Received: by 2002:a05:6000:4284:b0:435:a2f8:150d with SMTP id ffacd0b85a97d-43629385b15mr14097261f8f.59.1770630381235; Mon, 09 Feb 2026 01:46:21 -0800 (PST) X-Received: by 2002:a05:6000:4284:b0:435:a2f8:150d with SMTP id ffacd0b85a97d-43629385b15mr14097215f8f.59.1770630380758; Mon, 09 Feb 2026 01:46:20 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.129.40]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4362972fa4csm24313237f8f.26.2026.02.09.01.46.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Feb 2026 01:46:20 -0800 (PST) Date: Mon, 9 Feb 2026 10:46:18 +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: <20260207084550.GU1282955@noisy.programming.kicks-ass.net> 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);