linux-kernel - Re: [PATCH 15/21] mips: octeon: smp: Convert to hotplug state machine

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: <20160907142712.rr34s2c6xiwcrjaz@linutronix.de>
Date:   Wed, 7 Sep 2016 16:27:12 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Matt Redfearn <matt.redfearn@...tec.com>
Cc:     linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, rt@...utronix.de,
        tglx@...utronix.de, Ralf Baechle <ralf@...ux-mips.org>,
        linux-mips@...ux-mips.org
Subject: Re: [PATCH 15/21] mips: octeon: smp: Convert to hotplug state machine

On 2016-09-07 09:24:57 [+0100], Matt Redfearn wrote:
> HI Sebastian,
Hi Matt,

> > --- a/include/linux/cpuhotplug.h
> > +++ b/include/linux/cpuhotplug.h
> > @@ -44,6 +44,7 @@ enum cpuhp_state {
> >   	CPUHP_SH_SH3X_PREPARE,
> >   	CPUHP_X86_MICRCODE_PREPARE,
> >   	CPUHP_NOTF_ERR_INJ_PREPARE,
> > +	CPUHP_MIPS_CAVIUM_PREPARE,
> 
> But I'm curious why we have to create a new state here - this is going to
> get very unwieldy if every variant of every architecture has to have it's
> own state values in that enumeration. Can this use, what I assume is (and
> perhaps could be documented better in include/linux/cpuhotplug.h), the
> generic prepare state CPUHP_NOTIFY_PREPARE?

We can't share the states - one state is for one callback and one
callback only. If you want CPUHP_MIPS_PREPARE and you ensure that this
used only _once_ then this can be arranged.
For online states we have dynamic allocation of ids (which is what most
drivers should use). We don't have this of STARTING + PREPARE callbacks.

> Thanks,
> Matt
> 

Sebastian