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: <87o6rowrsp.ffs@tglx>
Date: Fri, 05 Sep 2025 22:47:02 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux PM
 <linux-pm@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>,
 Christian Loehle <christian.loehle@....com>, Dave Hansen
 <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v1] cpu: Add missing check to cpuhp_smt_enable()

On Fri, Sep 05 2025 at 15:27, Rafael J. Wysocki wrote:
> On Fri, Sep 5, 2025 at 3:13 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>> Well, manual online can be used for onlining the secondary thread of a
>> core where the primary thread is offline, so this is technically
>> possible already.
>>
>> > Something like the completely untested below.
>>
>> So given the above, shouldn't topology_is_core_online() check if any
>> thread in the given core is online?
>
> Besides, this would cause the siblings of offline SMT threads to be
> skipped while enabling SMT via sysfs (using
> /sys/devices/system/cpu/smt/control), but I'm not sure if this is the
> expectation in the field today.  The current behavior is to online all
> secondary SMT threads (and more, but that part is quite arguably
> broken).

It is broken, because the initial logic is to bring up primary threads
unconditionally and then refuse to bring up sibling threads.

With "maxcpus=xxx" this obviously limits the amount of primary threads,
so there is arguably no point to online any of the related secondary
threads of them.

The initial implementation was naively making that assumption, but the
core check which was added due to PPC made this actually correct.

It just did not snap with me back then, but it's actually the correct
thing to do, no?

Thanks,

        tglx




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ