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: <e2b4a90-2d9-f2db-8c85-2e64caed5d0@linutronix.de>
Date:   Thu, 24 Nov 2022 08:47:56 +0100 (CET)
From:   Anna-Maria Behnsen <anna-maria@...utronix.de>
To:     Frederic Weisbecker <frederic@...nel.org>
cc:     linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        John Stultz <jstultz@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Eric Dumazet <edumazet@...gle.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Arjan van de Ven <arjan@...radead.org>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Frederic Weisbecker <fweisbec@...il.com>,
        Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH v4 14/16] timer: Implement the hierarchical pull model

On Tue, 15 Nov 2022, Frederic Weisbecker wrote:

> On Fri, Nov 04, 2022 at 03:57:35PM +0100, Anna-Maria Behnsen wrote:
> > +static int tmigr_cpu_offline(unsigned int cpu)
> > +{
> > +	struct tmigr_cpu *tmc = this_cpu_ptr(&tmigr_cpu);
> > +
> > +	raw_spin_lock_irq(&tmc->lock);
> > +	tmc->online = 0;
> > +	__tmigr_cpu_deactivate(tmc, KTIME_MAX);
> 
> This means that if the CPU is going idle for some time during
> the hotplug process (ie: at some point between CPUHP_AP_TMIGR_ONLINE
> and CPUHP_TEARDOWN_CPU), then a global timer may be delayed for that long.
> 
> I guess it shouldn't be too bad but worth mentioning...
> 
> Although if it happens to be a problem it could be solved with simply allowing
> tmigr_cpu_deactivate() when !tmc->online.

The plan was (and I broke it) to let the CPU handle global timers by itself
as long as timer migration hierarchy is not completely initialized and as
long as CPU is marked offline in timer migration hierarchy. Otherwise
global timers might be delayed during this period. The proper way would be
that tmigr_cpu_deactivate(nextexp) directly returns nextexp if !tmc->online
and tmigr hierarchy is not in place yet. I will have a deeper look if there
was a reason why I changed the return to KTIME_MAX...

Thanks,

	Anna-Maria

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ