From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793876011; b=VP+wK8KIxXsagnzrZJbGi7BxjHKrbzz68rq1rxEyKxWnn160ACj1dEZ83Br63S5ITSat 4kVblfOsyvCMsvXDJye0RAKBNxh7W1KA5oVVWEyf7qCUasmmPfek6kUEofPUGjee8ePJT B4aYGpL7EzbvlZ/zIyrnegxisOf+MfSvBpqCzDUKf0C0ybOfRgYtxoV6fqDCIBmnj74K0 OagKToodc1tIZ/9saOHnBITAXHZfAX0TnJdFOf8gjOWlXW5gaFG1h+J9DMQo4sd1/AVP5 4QJz0wHZYofvW8ZovcNpJLWPhrDshMbTDk6AcHNkUf1sFWc8h9G0iOHfjB6aTahtbeQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793876011; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received: X-Received:Received:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=oydf0WShTzs9KXsUGEwBFf3FiP0jpqy13hriGlAhxmA=; b=sfhQ5ls7/NB5rDCn3jQRdvnDtIU7UTZ76zHnFe9l33ixZIRzkvx5c/uxXHY8ig1ZZ5WF lMecJWJ3jk5Zer9eMSbnMe7shNrhqp+pOmAtkXxZXA8l+CksvSWRM7sgIQm5+BCJJzTg1 OBNuCJ6r6l/O3KjiRiHkMPVUZ7KM6IfONDv7dhQxYm2W+fOS4AaBGee94QhSDysHuH6zW 4OhqO8UnViEeITPUPNqcgaD3GrqPUBrEWlWK6dfhTZuSWVV6934GzkDIS4IttQc9BAbjo 9T8NGThvtbJgBJ9NsiM9nAJ9mJgmdKI3HrKTx3vs8iK6NujtOLS/+403lNRYvemHhEg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=coSUly7e; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=VtW+CEHQ; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45BA9606A326 for ; Thu, 5 Nov 2026 10:53:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 45BA9606A326 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, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=coSUly7e; dkim=pass (2048-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=VtW+CEHQ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793876010; 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=oydf0WShTzs9KXsUGEwBFf3FiP0jpqy13hriGlAhxmA=; b=coSUly7eUCA6s9wSBg3Qafvdb9GXmwOP8aM7XuT1u4uNZBzpqUm/sEWg6uWpCtLSI6phvw l4+OfiUWINM3aja/5XJgcXFuHOkE0/zFrZF6AZHwawVxLol0fn1WoEhwqpUjGMgslK8YKO yeMlbLg3ZI7S51Wdn0qJukCkaFxmPfc= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-422-dOgFCjyeMN6D45qctjSpSg-1; Thu, 05 Nov 2026 05:53:29 -0500 X-MC-Unique: dOgFCjyeMN6D45qctjSpSg-1 X-Mimecast-MFC-AGG-ID: dOgFCjyeMN6D45qctjSpSg_1793876008 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4a318cd95e8so5773545e9.0 for ; Thu, 05 Nov 2026 02:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1793876008; x=1794480808; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=oydf0WShTzs9KXsUGEwBFf3FiP0jpqy13hriGlAhxmA=; b=VtW+CEHQzp//qCU9DsfU19uuTphWeRzF8nFxjH01RcG5AWiWLdFoD6sKq7iXP/Fiy3 xVTZD7/ZC9o2YWbhi5gxO0fTzSeWGgqnVXAa0tEmC9ee+G1ROZ02gWeWtZQCRxiOMFXH VrLj06klfHjQIOpI4tfVM1Nx2Fa2rINoBJAYmt+Se2kD5Fn3znrsGA8l+TKFHcQW8ETO JuO1JXW1fUaCpHmLApBp+CRUYizMExZbPO3PgWSPZuJQYblHoGINRKghV4lgJL9uhbnB mPsD9BRVp2QIl7ZYdIR2569h/6gDhzBvo5MHPXdJ5K+vY2m+XDQp9bdDSMQzndwMHaHC sxzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793876008; x=1794480808; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=oydf0WShTzs9KXsUGEwBFf3FiP0jpqy13hriGlAhxmA=; b=q4Fv3Kh6GgMDUQtUITtTpP9DdV4Me75lO9PklgEpWDM+HXO5Y43QbKzmjsCeaQZ1+/ 4/0ddl2h6kdroGNqs/EA9iajBwYefSLuz75y4Icm+li0QrFgDGXLK2eePGXxvNjqhBKd v3PrbHnnH3pBA+cBtOsHNGEz1yAt32nEyAQjStaJggmk/yztLC5ieQqINzlzJqbVL3zl gOGjdAmVAqHVQeA7cwaFg/YBLovH1Wfj8q35FqZll1StKI39Lupc8XD8m1PJHhVIKa47 kZEZQC4WcFdKuku1tM5uz6UhbOFyYLbOT1GCF71kAero8Mr1BZk+ZQnItERk2Xtp+ASb Oxaw== X-Forwarded-Encrypted: i=1; AKwUvBxV3gZ5gXeJcuxb7s6Z+ASFNw6YBRPoMCKNXSmkQtKDJq8KX2PdvaLwjSpgDWbh/2vB2tcmalRWF8aKy6o=@vger.kernel.org X-Gm-Message-State: APuU4Z/XSovi1qITLmqWlXA5doecYUJ1nQNOmmuHde/qGT3SdFv6Tcgd kupyiiW3RRFZzzLzZB9Bd1/1UgJh0OZyhtvcKhNvM16kHArvuz+zaXZtkNyr2/yY1DemiJvW2rs 9KM9sXpWi6bdQ6axr8Q2GmVD0iJISGz24dE9wyhmByScNInfiYyhLXjkqNGzWezFOVQ== X-Gm-Gg: AYBFou0luP1zmlYyTv/x+9EGfy7PjCf67xqFU/ITm5cfRQq3HAV76QAganKpaQB1J05 uFN9g01UreAcq4uUztbteoiyvgznLkyuCMH4HJnV240tRry8VRn/WfV0Cd2KI2hqBWvu60h6+F2 GDmYKYK2jfuqdXk/xMmqs2D0IkB2zPTW0L4nT11bzaFgPnwi63sOvE2b2kXJgH6LjNipjtAtr8w Hb6pdJ7LEGB21hogPbE5fbHsCe/3qo3fcFDiEzdsVZzQ8bKwQOPqxIJzs612zfFLxxVjTFQwd1F jB8mGUoAShEuaxJTN8ypOLrrVBkUGoseXFuS8HBUaZuCy/F5zPIbK7vyPHWh2KxzMQb4MprfbeC ZiflM8214j3iRvBOgV2GonLOHcyeMNVnpUhqanvFTzFBtYR0M9ErnRroBaupeo6t0Og8HAMfXY/ GxMw== X-Received: by 2002:a05:600c:1989:b0:4a1:88df:8a2a with SMTP id 5b1f17b1804b1-4b55dbb09dfmr39302605e9.13.1793876003239; Thu, 05 Nov 2026 02:53:23 -0800 (PST) X-Received: by 2002:a05:600c:1989:b0:4a1:88df:8a2a with SMTP id 5b1f17b1804b1-4b55dbb09dfmr39281275e9.13.1793875986470; Thu, 05 Nov 2026 02:53:06 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.158.90]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4b56eb4da1esm94641375e9.6.2026.11.05.02.53.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2026 02:53:05 -0800 (PST) Date: Thu, 5 Nov 2026 11:53:02 +0100 From: Juri Lelli To: Mathieu Desnoyers Cc: Peter Zijlstra , Ingo Molnar , Vincent Guittot , linux-kernel@vger.kernel.org, Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Luca Abeni , Mathieu Poirier , Waiman Long , Ridong Chen , Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , Shuah Khan , Sebastian Andrzej Siewior , Clark Williams , cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH v2 04/21] sched/deadline: Do not divide by zero active CPUs of a root domain Message-ID: References: <20261104211207.1392343-1-mathieu.desnoyers@efficios.com> <20261104211207.1392343-5-mathieu.desnoyers@efficios.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261104211207.1392343-5-mathieu.desnoyers@efficios.com> Hello, On 04/11/26 16:11, Mathieu Desnoyers wrote: > __dl_sub() and __dl_add() spread a change of a root domain's total_bw > over the extra_bw of its active CPUs, dividing it by their number, which > their callers take from dl_bw_cpus(). That number is 0 for a root domain > whose CPUs all went offline, such as the default root domain, which > holds the offline CPUs: the division then traps. > > A debugfs write of a fair server's runtime or period reaches it while > its CPU goes offline or comes online. From the rebuild of the root > domains in sched_cpu_deactivate() until the CPU is offline, and from the > CPU online until sched_cpu_activate(), the CPU sits in the default root > domain, with no active CPU. A write that leaves the server's bandwidth > as it is passes admission there, __dl_overflow() comparing that root > domain's capacity, 0, with total_bw less the old bandwidth plus the new, > 0 as well, and dl_server_apply_params() divides. Any other value is > refused with EBUSY, higher directly, lower through the unsigned > subtraction. Once the CPU is offline the write is refused, since > commit 4043f5498416 ("sched/deadline: Reject debugfs dl_server writes > for offline CPUs"). > > Writing a fair server's own runtime back in a loop while its CPU goes > offline and online oopses on the first round, in 8-CPU VMs of v7.4-rc1 > with the four deadline fixes of sched/urgent: > > Oops: divide error: 0000 [#1] SMP NOPTI > CPU: 6 UID: 0 PID: 110 Comm: dl_server_div0 > RIP: 0010:dl_server_apply_params+0x335/0x380 > Call Trace: > > sched_server_write_common.isra.0+0x1c0/0x260 > full_proxy_write+0x58/0x90 > vfs_write+0xcb/0x550 > ksys_write+0x6c/0xe0 > do_syscall_64+0x109/0x5d0 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > inactive_task_timer() can reach it too, found by reading: it releases > the bandwidth of a task that left SCHED_DEADLINE, or died, before its > 0-lag time from the root domain of the CPU the task is on, and that CPU > may go offline before the timer fires. With admission control off, so > may sched_setattr() to SCHED_DEADLINE of a task asleep on an offline > CPU. > > With no active CPU there is no extra_bw to update: change total_bw > alone. 20 rounds of the reproducer leave no warning then. > > Fixes: daec57983670 ("sched/deadline: Reclaim bandwidth not used by dl tasks") > Signed-off-by: Mathieu Desnoyers > --- > kernel/sched/deadline.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index 963fda6ddb7f..dadda1a528ec 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -189,18 +189,25 @@ void __dl_update(struct dl_bw *dl_b, s64 bw) > } > } > > +/* > + * @cpus is the number of active CPUs of the root domain, whose extra_bw > + * shares the change: none once they all went offline, and total_bw alone > + * changes then. > + */ > static inline > void __dl_sub(struct dl_bw *dl_b, u64 tsk_bw, int cpus) > { > dl_b->total_bw -= tsk_bw; > - __dl_update(dl_b, (s32)tsk_bw / cpus); > + if (cpus) > + __dl_update(dl_b, (s32)tsk_bw / cpus); > } > > static inline > void __dl_add(struct dl_bw *dl_b, u64 tsk_bw, int cpus) > { > dl_b->total_bw += tsk_bw; > - __dl_update(dl_b, -((s32)tsk_bw / cpus)); > + if (cpus) > + __dl_update(dl_b, -((s32)tsk_bw / cpus)); > } I wonder if it makes sense to add/sub from total_bw when cpus == 0. Wouldn't be better, if possible, to avoid calls with 0 cpus? Thanks, Juri