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 CC40D3AE6E6 for ; Fri, 29 May 2026 09:14:37 +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=1780046080; cv=none; b=J4IV7Q2k4fdlsDEIbslLYz6kO8bWkGWrc+2V64QH3xqcaVmW9bdhyRKlG9a6DAstbSLOZzOvZaVwBFDhaYmxOQ1h/C+6HtKDTqHlykbN4GLZaFgtilky12GZAh6LTNUB3Q6Sca5sDpFN5NRuKJgpZjCnKtNZetMTAKtduKBmq/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780046080; c=relaxed/simple; bh=Ec9l1/N7wHlsf1BdjlUHZ6Ql2KuMA81XoM//joJvjRQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dV5Twtyp0N2a5MOIiJNQ9OSx0YL9HnSO0D5fc4SZXg9C2qXUyiKOSmH1GtqDrUTzVy6d2gC+NEc3F3jIQhmen5mmzXdSjJM9gRHL9qViUL2MBifIhvHABcrW4xOHHQs3QsrsrC73mIgad2PdwXBvdZzAhYsNB8YpOU8Ibi1pcpU= 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=MpVkOXtQ; 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="MpVkOXtQ" 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=dOCAu2EIKmaDEdfBdYHnBcym8gK0XOHocv+lFAceQWo=; b=MpVkOXtQexqcc4stofJj81GgAH 3pGwIsVV41lMpHgZgwqQjPt9Pe93ZNzPyeRM24U13oRMuQ3S8egqLqovSLJ+8O40pVtHuU52wOpiY m3C4UpuD0SoKZRAW/x3lor4LOh4NjuGbhibMTjHVR/0MGxgv6A8ZRU6+ZgIvBmfL2bS6cUN0S5VFi PENA8fydazY7MU4CwFE/82TjbeV6wFBCCabWZOIVYTO9zuAc7jZcAJepnzUsd55WJ7EeFTzCf9+ND toKuylKceQrNMdbsd3jinf8jm87HtEFnlGF85IBGoNFWbCf8VsNKlYLD8KaN/AZGUHOP+0Jyyo3Vp bXP8EjkQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wStIS-00000005qXB-2nlY; Fri, 29 May 2026 09:14:28 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 7DEBE300324; Fri, 29 May 2026 11:14:27 +0200 (CEST) Date: Fri, 29 May 2026 11:14:27 +0200 From: Peter Zijlstra To: Andrea Righi Cc: Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , linux-kernel@vger.kernel.org, Sashiko Subject: Re: [PATCH] sched/deadline: Reject debugfs dl_server writes for offline CPUs Message-ID: <20260529091427.GN343181@noisy.programming.kicks-ass.net> References: <20260526100502.575774-1-arighi@nvidia.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: On Fri, May 29, 2026 at 09:09:30AM +0200, Andrea Righi wrote: > Hi Peter, > > On Tue, May 26, 2026 at 02:07:53PM +0200, Juri Lelli wrote: > > Hi Andrea, > > > > On 26/05/26 12:05, Andrea Righi wrote: > > > Writing runtime or period via the per-CPU dl_server debugfs files > > > (/sys/kernel/debug/sched/{fair,ext}_server/cpu*/{runtime,period}) on an > > > offline CPU can trigger two distinct kernel issues: > > > > > > 1) Divide-by-zero in dl_server_apply_params(): > > > > > > Oops: divide error: 0000 [#1] SMP NOPTI > > > RIP: 0010:dl_server_apply_params+0x239/0x3a0 > > > Call Trace: > > > sched_server_write_common.isra.0+0x21a/0x3c0 > > > full_proxy_write+0x78/0xd0 > > > vfs_write+0xe7/0x6e0 > > > > > > Both __dl_sub() and __dl_add() divide by cpus internally, which can be > > > 0 once the CPU has been removed from any active root-domain span (this > > > has been latent since the debugfs interface was introduced). > > > > > > 2) WARN_ON_ONCE in dl_server_start(): > > > > > > WARNING: kernel/sched/deadline.c:1805 at dl_server_start+0x232/0x270 > > > > > > Commit ee6e44dfe6e5 ("sched/deadline: Stop dl_server before CPU goes > > > offline") added this check to catch enqueueing the server on an > > > offline rq. > > > > > > There's no meaningful semantics for re-configuring the per-CPU dl_server > > > bandwidth while the CPU is offline, so simply reject the write with > > > -EBUSY so userspace gets a clear error. > > > > > > Reported-by: Sashiko > > > Closes: https://lore.kernel.org/all/20260526092228.3B6891F00A3A@smtp.kernel.org/ > > > Fixes: d741f297bcea ("sched/fair: Fair server interface") > > > Signed-off-by: Andrea Righi > > > --- > > > kernel/sched/debug.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c > > > index ed3a0d65da0ca..e57ad8c78a60e 100644 > > > --- a/kernel/sched/debug.c > > > +++ b/kernel/sched/debug.c > > > @@ -415,6 +415,9 @@ static ssize_t sched_server_write_common(struct file *filp, const char __user *u > > > return -EINVAL; > > > } > > > > > > + if (!cpu_online(cpu_of(rq))) > > > + return -EBUSY; > > > + > > > update_rq_clock(rq); > > > dl_server_stop(dl_se); > > > retval = dl_server_apply_params(dl_se, runtime, period, 0); > > > > I was looking at Sashiko findings and wondered what to do about this as > > well. I think what you are proposing should be fine, unless for some > > reason one wants to tweak dl-server parameters before swithcing a CPU > > on. but since hotplug it's a disruptive operation already, I would say > > imposing to make such a change after CPU is online should be ok (and > > simpler to get right from a bandwidth accounting pov). > > > > Reviewed-by: Juri Lelli > > If this makes sense to you, could you add it to your queue:sched/core? > > Otherwise it's possible to trigger the issues above by changing dl_server > bandwidth for offline CPUs. Right, so I had seen these patches fly by, but then I couldn't find it in a hurry when I took these other patches :/. It is a bit unfortunate, but oh well. I'm sure people will try and fix it if they're too annoyed by this behaviour and we can revisit thing then. So yes, let me go add this to the other two.