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 42EE638333C for ; Thu, 13 Aug 2026 08:32:40 +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=1786609962; cv=none; b=imofpFLqeCjZJt9dXM94rFRY5sRsna0TXUfA2Qfr7ZveKoCb4UMD6WDXx3+8ii2+jGalUa6j8RllZV6eoGNN+cjQ6NpeeUzPl/vBvwMUALeRLOlZcYcvjj1Yu6520ynwS503MybZf/0LMtieqFCeQ0YWPm1vhtUs/oUvqy0acRQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786609962; c=relaxed/simple; bh=V31mtVq++AV5mI1pQg/5KGwOQEZnJDCtH4REbIgX/ZE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dSq0CJKqxkPbBUOYWfg4MfiKeepC707+EdYVVrUiKWj5e+nMNqaTLUrYoPpEMEQ1JOd8/fvJWRsONLlypA05zoPDMlD32x1qzL32oSzKsAXdyymfUMMeXvZy7fAMq5O1myA4ebu4mAaQSHcFxrHxNCFVY422YmkN7aCfEZrKnOg= 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=f84Thr5C; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Nh2hHqhN; 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="f84Thr5C"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Nh2hHqhN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786609959; 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=ZniUuYgFzj/H+T8JGMMvMkk+yWBd0ZWaOpV1t/iwa4A=; b=f84Thr5Cf3AgJg7H/eHmT/GTrCGQw2013Z6+uONBdG028+FFsSAII1Tgk2YLIggczpsNkm 9yNta9hR1ti0Hl3nrImvZ42p/jQd7MOj1OHzOK6GgzrfVtO3YArodJbhRmJB7ZLXO5xUVf DkwZGkJSEVHof3YmTZljTmZTRV58wcI= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-232-Ak-xy_y4OUKkWCL-8yXaTg-1; Thu, 13 Aug 2026 04:32:36 -0400 X-MC-Unique: Ak-xy_y4OUKkWCL-8yXaTg-1 X-Mimecast-MFC-AGG-ID: Ak-xy_y4OUKkWCL-8yXaTg_1786609955 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-496c06ba017so4758285e9.0 for ; Thu, 13 Aug 2026 01:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786609955; x=1787214755; 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=ZniUuYgFzj/H+T8JGMMvMkk+yWBd0ZWaOpV1t/iwa4A=; b=Nh2hHqhN+sYCgTHnvp6o/0uPR5l8KaFvlbokJVldIhEBhFudvzj4o+qkoA+Y1WGbUF QPM1omdeNN6fN1Ws0VsHBnLsR2iXLM3Q5exz37wQaRq9iXC13GHY6G3tpCPPjZy6anGp scRBRgf9Jj0xWjMLiBig32CZtCKvMDAKTOu3P+JCteD5weBhp+neW5LIh/+cMyHXJB8L IEgRj7axns5OEhgSsbBF/5LO6+rp3DBCBY6JAs9tSn5I+0S2umVfGPyxSDi5DQfjXfJi p3sqgV2G/aV+HJ+s6BFg7A9u46co9rrp2V4m5ExZ8szkcbbewwQAqhSfelU630G7rt1x CvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786609955; x=1787214755; 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=ZniUuYgFzj/H+T8JGMMvMkk+yWBd0ZWaOpV1t/iwa4A=; b=gy4eleAZ+ghK8HlP3m/w3qWeLG8Ibb4UgWddGwgM4VqnT9oYjlQffCher36raE1Fp5 eYxfqTO+ta9ZXStQD9UYlRdS00DSt/yTeUlAm6We5vZ55iyzkOVSPxpVWvPfZlmr38QE xSnHb109OaCMS+GXsgFrnXvEHCS9u0sFZy2yfH6teUlYA43xHYwfJZaJnvOqeCCAURmX tRnVk/dHwCUfjR63kbHNNoLrqcNMn2SiHozZjtpp0ut2qrVGbbHiFRel/EzC/iVxQKSw m4sOHuUyi1ffV4AM4dSxu9iPDN38g/PT2g5G+ZtYBAVOznc1KPpdDmJ51HK9e9cIk0tP FRPQ== X-Forwarded-Encrypted: i=1; AHgh+RokPIfBJdMOOTYyZi2mLOkTEAbnGRzM7xoS2ZVo04edCsQRyCRyZQUU+3ajq6QOtIgmaZiP0GyMfKkWpyI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzl4D6CnYr0pkyPJCiNhwlW4z+qsiHEm7QPwU4V0G7qsgM98LCo jEekSNygVMyFnGf3wPdWtqlyNSneOt/ETf97Wk4n66MwE6w/pbp333a7LkCmg56asxBnR5V6ABL TjxYejSLK1ttTuUprkeqNWKsKvhJe3JlF4d9c2iVesSpLUP5XdMzpHFq2QMNPrqfufA== X-Gm-Gg: AR+sD13zWUfwppvM8w8Zy+4TNiM0MrHo4yuq6p0oMR28KvHEFirU2qIojnVh2Fn4jU/ hgW5Ld2RNosQeFxMlNyh0Bmls5o8MZQ2B9k+Bwta2K8RmhhKx/KuzyF5DElYEaZilXPnK0DlPT6 HA//cX8zuSiI19bbXXxtssfIA9DAl5cpLROEBKyYnbEnK+L6HxZwhwhVUpBH4Uc39NAZubYpCyn iQLL4ESWnij8oVNhqPB8ZgDtQAY9pWKzYomPBI4o7EuEB0PnzpUr00cPMA67zjswYWIjpvCPO+f MvFN635zh4F1QNaLOCXMI7Mx6w/MrRPzf5Ga4RLMVy5HXlTcWqioH+Jw/+hX/yNOnj/KGIHsk/3 XnBS8rV/36PXY3aHLP4rFnwoLo8tZ19U= X-Received: by 2002:a05:600d:8489:10b0:495:7aaf:77b with SMTP id 5b1f17b1804b1-49982107b89mr37500645e9.0.1786609954812; Thu, 13 Aug 2026 01:32:34 -0700 (PDT) X-Received: by 2002:a05:600d:8489:10b0:495:7aaf:77b with SMTP id 5b1f17b1804b1-49982107b89mr37499885e9.0.1786609954458; Thu, 13 Aug 2026 01:32:34 -0700 (PDT) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.92.144]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815a5af19fsm4548225f8f.24.2026.08.13.01.32.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 01:32:33 -0700 (PDT) Date: Thu, 13 Aug 2026 10:32:31 +0200 From: Juri Lelli To: Hui Su Cc: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Sashiko Subject: Re: [PATCH] sched/deadline: Fix DL server divide-by-zero for inactive CPUs Message-ID: References: <20260812123252.2355986-3-sh_def@163.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: <20260812123252.2355986-3-sh_def@163.com> Hello, On 12/08/26 20:32, Hui Su wrote: > Commit 4043f5498416 ("sched/deadline: Reject debugfs dl_server writes > for offline CPUs") rejects per-CPU DL server parameter updates once the > target CPU is offline. However, during CPU hot-unplug, the CPU is cleared > from cpu_active_mask before it is marked offline. > > This leaves a window where cpu_online() is still true while > cpu_active() is already false. A debugfs write during this window passes > the cpu_online() check in sched_server_write_common() and reaches > dl_server_apply_params() with init=false. > > dl_bw_cpus() counts the active CPUs in the root domain. For an isolated > CPU whose root-domain span contains only that CPU, it returns zero once > the CPU becomes inactive. If the server bandwidth is attached, > dl_server_apply_params() then passes this zero CPU count to __dl_sub() > and __dl_add(), both of which divide by the CPU count. > > Using CPU1 with isolcpus=domain,1 and a temporary local hotplug pause > hook to stop the teardown after cpu_active_mask was cleared but before > the CPU became offline reproduced the state as: > > dl_bw_cpus=0 attached=1 dl_b->bw=-1 total_bw=52428 span=1 active=0 > > Writing a new fair-server runtime while CPU1 was held in that state > triggered: > > # echo 40000000 > /sys/kernel/debug/sched/fair_server/cpu1/runtime > > Oops: divide error: 0000 [#1] SMP NOPTI > RIP: 0010:dl_server_apply_params+0x39d/0x400 > Call Trace: > sched_server_write_common.isra.0+0x1d2/0x2d0 > full_proxy_write+0x64/0x90 > vfs_write+0xf7/0x540 > ksys_write+0x6e/0xf0 > > Reject DL server parameter writes when the target CPU is inactive, not > only when it is offline. > > Also update root-domain bandwidth in dl_server_apply_params() only while > the target CPU is active. This second check is necessary because CPU > hot-unplug can race with the debugfs path after its CPU state check and > before dl_server_apply_params() updates the bandwidth. > > Keep the runqueue-local utilization update independent of cpu_active() > so that the local bandwidth state remains consistent if the CPU becomes > inactive during the parameter update. > > With the fix, a write during the same hot-unplug window is rejected with > -EBUSY instead of reaching __dl_sub() or __dl_add() with a zero CPU > count. > > Fixes: d741f297bcea ("sched/fair: Fair server interface") > Reported-by: Sashiko > Link: https://lore.kernel.org/r/anw7IML1xzHys6re@jlelli-thinkpadt14gen4.remote.csb > Cc: stable@vger.kernel.org > Signed-off-by: Hui Su > --- Looks good to me, thanks! Acked-by: Juri Lelli Best, Juri