From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 99B9131E107 for ; Mon, 2 Mar 2026 14:48:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772462897; cv=none; b=MKBi1VfmSDLxqAmlBub8QNqCrX7oeYJgDs3Kcdev5+xXUJjJe3Dglb0c8l7phzvQu9BUfeoUJMEv+V++cg+u0lJuYbUkPTgUQqmNNinmMZcHkI4pjcsBsho5ke9+BYT9di17L1ZTX/lBj9y8+C7btdNb4LXwy5evUahj+rkKHW4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772462897; c=relaxed/simple; bh=0aNksym0VCwKOAk25RrKLZvROChJ13iQ+HijNVxgNkI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CnCHVoXTAx1fdVZfZL2H8Ol/4+kuxPfSxZb2TayOgcDVbNX7OHqx7G+OUJqs0Wea3c6YBXxAdWXD/N9sUlmJdsuYvb4jQGLYGmRFoueA1Yc0jGpdTg8KfnlRah0NHEQiM55vINYYtuUnSczUete544wEZLaX/cv0jq2iPrQZN2Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=NVBTE2qw; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="NVBTE2qw" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=XRJuFGNJFIFcMXwsxWzwO8NY6wO4A4c32njq3aMEfko=; b=NVBTE2qwFL2jkYN6T8urEETiNH ZdgFUC6LIZR1iyUQnQvuhY/t/axgmicgXIn2gLzDNavoWuYuweZ6avhbQOHx19z+ed9f72aSmpWQ+ qjLGDl2p8rlcCpifdvcY5kfM+iEClnmASZxvPgW7MqTJWLGg/mDhzZoZoYxHAl0gf4ReIb+bGbzT4 CnM0p3LsBa4m35WpAzvfM3sAlRXlfZjIglWAbu91Lk5xuEBDXo+130MbBBRbrSp2YXwHMB8ojMs8D VzBeNQMR8kGn9bHWLlNgbY10A+qwE6wOLIlWHY6OwK8tsKlUh10f2CrJrBbATQ5/qbQqCF1z0W7km oxBTMDfQ==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vx4Z7-00000009dAr-32wb; Mon, 02 Mar 2026 14:48:09 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 4BF59300B40; Mon, 02 Mar 2026 15:48:08 +0100 (CET) Date: Mon, 2 Mar 2026 15:48:08 +0100 From: Peter Zijlstra To: Juri Lelli 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 v2] sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting Message-ID: <20260302144808.GG1395266@noisy.programming.kicks-ass.net> References: <20260302-upstream-fix-deadline-piboost-b4-v2-1-0c92b737f13c@redhat.com> 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: <20260302-upstream-fix-deadline-piboost-b4-v2-1-0c92b737f13c@redhat.com> On Mon, Mar 02, 2026 at 11:01:00AM +0100, Juri Lelli wrote: > Running stress-ng --schedpolicy 0 on an RT kernel on a big machine > might lead to the following WARNINGs (edited). > > sched: DL de-boosted task PID 22725: REPLENISH flag missing > > WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 > ... (running_bw underflow) > Call trace: > dequeue_task_dl+0x15c/0x1f8 (P) > dequeue_task+0x80/0x168 > deactivate_task+0x24/0x50 > push_dl_task+0x264/0x2e0 > dl_task_timer+0x1b0/0x228 > __hrtimer_run_queues+0x188/0x378 > hrtimer_interrupt+0xfc/0x260 > arch_timer_handler_phys+0x34/0x60 > handle_percpu_devid_irq+0xa4/0x230 > generic_handle_domain_irq+0x34/0x60 > __gic_handle_irq_from_irqson.isra.0+0x158/0x298 > gic_handle_irq+0x28/0x80 > call_on_irq_stack+0x30/0x48 > do_interrupt_handler+0xdc/0xe8 > el1_interrupt+0x44/0xc0 > el1h_64_irq_handler+0x18/0x28 > el1h_64_irq+0x80/0x88 > cpuidle_enter_state+0xc4/0x520 (P) > cpuidle_enter+0x40/0x60 > cpuidle_idle_call+0x13c/0x220 > do_idle+0xa4/0x120 > cpu_startup_entry+0x40/0x50 > secondary_start_kernel+0xe4/0x128 > __secondary_switched+0xc0/0xc8 > > The problem is that when a SCHED_DEADLINE task (lock holder) is > changed to a lower priority class via sched_setscheduler(), it may > fail to properly inherit the parameters of potential DEADLINE donors > if it didn't already inherit them in the past (shorter deadline than > donor's at that time). This might lead to bandwidth accounting > corruption, as enqueue_task_dl() won't recognize the lock holder as > boosted. > > The scenario occurs when: > 1. A DEADLINE task (donor) blocks on a PI mutex held by another > DEADLINE task (holder), but the holder doesn't inherit parameters > (e.g., it already has a shorter deadline) > 2. sched_setscheduler() changes the holder from DEADLINE to a lower > class while still holding the mutex > 3. The holder should now inherit DEADLINE parameters from the donor > and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen > > Fix the issue by introducing __setscheduler_dl_pi(), which detects when > a DEADLINE (proper or boosted) task gets setscheduled to a lower > priority class. In case, the function makes the task inherit DEADLINE > parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to > ensure proper bandwidth accounting during the next enqueue operation. > > Reported-by: Bruno Goncalves > Signed-off-by: Juri Lelli Does this thing want a Fixes? Also, perhaps trim the WARN to the bare minimum required?