linux-kernel - Re: [PATCH] sched/deadline: Derive root domain from active cpu in task's cpus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF+s44Q_zOErWe11GydBnNKfntPV9LDWtAyvJbL533o7US3_aw@mail.gmail.com>
Date: Thu, 16 Oct 2025 20:20:49 +0800
From: Pingfan Liu <piliu@...hat.com>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Pierre Gondois <pierre.gondois@....com>, Peter Zijlstra <peterz@...radead.org>, 
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>, 
	Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>, 
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, 
	Valentin Schneider <vschneid@...hat.com>
Subject: Re: [PATCH] sched/deadline: Derive root domain from active cpu in
 task's cpus_ptr

On Wed, Oct 15, 2025 at 5:35 PM Juri Lelli <juri.lelli@...hat.com> wrote:
>
[...]
> > > Then kexec to another kernel. The available bandwidth of the root domain
> > > gradually decreases with the number of CPUs unplugged.
> > > At some point, there is not enough bandwidth and an overflow is detected.
> > > (Same call stack as in the original message).
>
> I seem to agree with Pingfan below, kexec (kernel crash?) is a case

It is kexec-rebooting, not crashing. The crash just leaves the other
cpus in loop instead of offlining them.

> where all guarantees are out of the window anyway, so really no point in
> keeping track of bandwidth and failing hotplug. Guess we should be
> adding an ad-hoc check/bail for this case.
>

I have finished patches for this issue, but have some trouble getting
a machine to verify it.  I will send it out later.


Thanks,

Pingfan

> > > So I'm not sure this is really related to the cppc_fie thread.
> > > I think it's more related to checking the available bandwidth in a context
> > > which is not appropriate. The deadline bandwidth might lack when the
> > > platform
> > > is reset, but this should not be that important.
> > >
> >
> > I think there are two independent issues.
> >
> > In your experiment, as CPUs are hot-removed one by one, at some point
> > the hot-removal will fail due to insufficient DL bandwidth. There
> > should be a warning message to inform users about what's happening,
> > and users can then remove some DL tasks to continue the CPU
> > hot-removal.
> >
> > Meanwhile, in the kexec case, this checking can be skipped since the
> > system cannot roll back to a working state anyway
> >
> >
> > Thanks,
> >
> > Pingfan
> > > ---
> > >
> > > Question:
> > > Since the cppc_fie worker doesn't have the SCHED_FLAG_SUGOV flag,
> > > is this comment actually correct ?
> > > /*
> > >   * Fake (unused) bandwidth; workaround to "fix"
> > >   * priority inheritance.
> > >   */
> > >
> > > ---
> > >
> > > On a non-deadline related topic, the CPPC drivers creates a cppc_fie
> > > worker in
> > > case the CPPC counters to estimate the current frequency are in PCC
> > > channels.
> > > Accessing these channels requires to go through sleeping sections,
> > > that's why a worker is used.
> > >
> > > However, CPPC counters might be accessed through FFH, which doesn't go
> > > through
> > > sleeping sections. In such case, the cppc_fie worker is never used and never
> > > removed, so it would be nice to remote it.
> > >
> >
>