linux-kernel - Re: [PATCH] cpu/hotplug: Create SMT sysfs interface for all arches

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: <20190326133236.lylrrbacznezybjm@treble>
Date:   Tue, 26 Mar 2019 08:32:36 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Waiman Long <longman@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Jiri Kosina <jikos@...nel.org>
Subject: Re: [PATCH] cpu/hotplug: Create SMT sysfs interface for all arches

On Sun, Mar 24, 2019 at 09:13:18PM +0100, Thomas Gleixner wrote:
> On Fri, 1 Mar 2019, Josh Poimboeuf wrote:
> > Make the /sys/devices/system/cpu/smt/* files available on all arches, so
> > user space has a consistent way to detect whether SMT is enabled.
> > 
> > The 'control' file now shows 'notsupported' for architectures which
> > don't yet have CONFIG_HOTPLUG_SMT.
> 
> I'm slowly crawling through my backlog ...
> 
> > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> > @@ -514,7 +514,8 @@ Description:	Control Symetric Multi Threading (SMT)
> >  			 "on"		SMT is enabled
> >  			 "off"		SMT is disabled
> >  			 "forceoff"	SMT is force disabled. Cannot be changed.
> > -			 "notsupported" SMT is not supported by the CPU
> > +			 "notsupported" Runtime SMT toggling is not currently
> > +					supported for the architecture
> 
> Second thoughts. I'm not really convinced that changing the meaning of
> notsupported and in fact overloading it, is the right thing to do.
> notsupported means now:
> 
>   CPU does not support it - OR - architecture does not support it
> 
> That's not pretty and we are surely not short of state space. There are
> several options for handling this:
> 
>  1) Do not expose the state file, just expose the active file
> 
>  2) Expose the state file, but return -ENOTSUPP or some other sensible error
>     code
> 
>  3) Expose the state file and let show return 'notimplemented' which is
>     more accurate. That wouldn't even require to expand the state space
>     enum. It just can be returned unconditionally.

Makes sense.  I like #3.  I can post another version.

-- 
Josh