linux-kernel - Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

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: <20191210205348.GA4080658@kroah.com>
Date:   Tue, 10 Dec 2019 21:53:48 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Thomas Renninger <trenn@...e.de>, linux-kernel@...r.kernel.org,
        Felix Schnizlein <fschnizlein@...e.de>,
        linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux@...linux.org.uk, will.deacon@....com, x86@...nel.org,
        fschnitzlein@...e.de, Felix Schnizlein <fschnizlein@...e.com>,
        Thomas Renninger <trenn@...e.com>
Subject: Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

On Tue, Dec 10, 2019 at 09:48:54PM +0100, Thomas Gleixner wrote:
> Greg KH <gregkh@...uxfoundation.org> writes:
> > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> >> From: Felix Schnizlein <fschnizlein@...e.de>
> >> ==> flags <==
> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip
> >
> > One file with all of that?  We are going to run into problems
> > eventually, that should be split up.
> >
> > Just like bugs, that's going to just grow over time and eventually
> > overflow PAGE_SIZE :(
> >
> > Make this:
> >   ├── flags
> >   │   ├── fpu
> >   │   ├── vme
> > ...
> >
> > Much simpler to parse, right?
> 
> Well, I'm not really sure whether 100+ files are simpler to parse.
> 
> Aside of that I really don't see the value for 100+ files per CPU which
> are just returning 1 or True or whatever as long as you are not
> suggesting to provide real feature files which have 0/1 or True/False
> content.
> 
> But I still don't get the whole thing. The only "argument" I've seen so
> far is the 'proc moves to sys' mantra, but that does not make it any
> better.

That is not a valid mantra, as I tried to explain later in this thread.

I don't understand the need for this patchset either, all I was trying
to do was to at least make it sane from a sysfs-point-of-view if people
really wanted to do this type of thing.

> We won't get rid of /proc/cpuinfo for a very long time simply because
> too much userspace uses it. Introducing a mess in /sys/ in parallel just
> for following the mantra does not help much.

Again, invalid mantra, not a valid reason :)

I think this is a patchset in search of a problem, which is why it was
dropped all those years ago...

thanks,

greg k-h