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] [day] [month] [year] [list]
Message-ID: <Yzrtp9wDUED+72w8@lorien.usersys.redhat.com>
Date:   Mon, 3 Oct 2022 10:11:51 -0400
From:   Phil Auld <pauld@...hat.com>
To:     linux-kernel@...r.kernel.org
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Valentin Schneider <vschneid@...hat.com>,
        Steven Price <steven.price@....com>,
        Mark Rutland <mark.rutland@....com>,
        Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [RESEND PATCH v4 0/2] cpuhp: fix some st->target issues

On Thu, Sep 15, 2022 at 11:37:49AM -0400 Phil Auld wrote:
> Fix a couple of cpuhp inconsistencies.
> 
> The first prevents target_store() from calling cpu_down() when
> target == state which prevents the cpu being incorrectly marked
> as dying.  The second just makes the boot cpu have a valid cpuhp
> target rather than 0 (CPU_OFFLINE) while being in state
> CPU_ONLINE.
> 
> A further issue which these two patches don't address is that
> the cpuX/online file looks at the device->offline state and can
> thus get out of sync with the actual cpuhp state if the cpuhp
> target is used to change state.
> 
> v3: Added code to make sure st->target == target in the nop case.
> 
> v4: Use WARN_ON in the case where state == target but st->target does
> not.
> 
> Phil Auld (2):
>   cpuhp: make target_store() a nop when target == state
>   cpuhp: Set cpuhp target for boot cpu
> 
>  kernel/cpu.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> -- 
> 2.31.1
> 

Pingy McPing-face :)

Peter?  Anyone?   It's really not ideal to have a cpu marked dying when
it isn't actually going down. Please take a look. 

Thanks for your time.

Cheers,
Phil

-- 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ