linux-kernel - Re: [PATCH v4 2/2] perf x86: Exposing an Uncore unit to PMON for Intel Xeon® server platform

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]

Date:   Fri, 17 Jan 2020 15:19:44 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     roman.sudarikov@...ux.intel.com
Cc:     peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...hat.com, namhyung@...nel.org,
        linux-kernel@...r.kernel.org, eranian@...gle.com,
        bgregg@...flix.com, ak@...ux.intel.com, kan.liang@...ux.intel.com,
        alexander.antonov@...el.com
Subject: Re: [PATCH v4 2/2] perf x86: Exposing an Uncore unit to PMON for Intel Xeon® server platform

On Fri, Jan 17, 2020 at 04:37:59PM +0300, roman.sudarikov@...ux.intel.com wrote:
> From: Roman Sudarikov <roman.sudarikov@...ux.intel.com>
> 
> Current version supports a server line starting Intel® Xeon® Processor
> Scalable Family and introduces mapping for IIO Uncore units only.
> Other units can be added on demand.
> 
> IIO stack to PMON mapping is exposed through:
>     /sys/devices/uncore_iio_<pmu_idx>/mapping
>     in the following format: domain:bus
> 
> For example, on a 4-die Intel Xeon® server platform:
>     $ cat /sys/devices/uncore_iio_0/mapping
>     0000:00,0000:40,0000:80,0000:c0

Again, horrible format, why do we have to parse this in userspace like
this?  Who will use this file?  What do they really need?

And what happens when you have too many "dies" in a system and you
overflow the sysfs file?  We have already seen this happen for other
sysfs files that assumed "oh, we will never have that many
cpus/leds/whatever in a system at one time" and now they have to go do
horrid hacks to get around the PAGE_SIZE limitation of sysfs files.

DO NOT DO THIS!

I thought I was nice and gentle last time and said that this was a
really bad idea and you would fix it up.  That didn't happen, so I am
being explicit here, THIS IS NOT AN ACCEPTABLE FILE OUTPUT FOR A SYSFS
FILE.

greg k-h