linux-kernel - Re: [PATCH 2/7] perf: Create a symlink for a PMU

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:   Thu, 24 Jun 2021 08:24:29 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     Greg KH <greg@...ah.com>
Cc:     kan.liang@...ux.intel.com, peterz@...radead.org, mingo@...hat.com,
        linux-kernel@...r.kernel.org, eranian@...gle.com,
        namhyung@...nel.org, acme@...nel.org, jolsa@...hat.com
Subject: Re: [PATCH 2/7] perf: Create a symlink for a PMU

On 6/24/2021 7:29 AM, Greg KH wrote:
> On Thu, Jun 24, 2021 at 07:24:31AM -0700, Andi Kleen wrote:
>>> But first off, why is this symlink suddenly needed?  What is so special
>>> about this new hardware that it breaks the existing model?
>> The driver can be in two modes:
>>
>> - Driver fully knows the hardware and puts in the correct Linux names
>>
>> - Driver doesn't know the hardware but is in a fallback mode where it only
>> looks at a discovery table. There we don't have the correct names, just an
>> numeric identifier for the different hardware sub components.
> Why does this matter?  Why would the driver not "know" the hardware?  If
> it doesn't know it, why would it bind to it?

It's a similar concept as a PCI class. How to have a driver that can 
handle future hardware, but with some restrictions

The perf CPU PMU has had a similar concept for a long time. The driver 
can be either in architectural mode (with a subset of features), or be 
fully enabled. This allows users who are on an older kernel to still use 
at least a subset of the functionality.

It will bind as long as the discovery table is there.

>
>> In the later mode the numeric identifier is used in sysfs, in the former
>> case the full Linux name. But we want to keep some degree of Linux user
>> space compatibility between the two, that is why the full mode creates a
>> symlink from the "numeric" name. This way the (ugly) identifiers needed for
>> the fallback mode work everywhere.
> So what _exactly_ does the symlink do here?  What is it from->to?

It's from numeric identifier to full perf name

In fallback mode there is no symlink, only the numeric identifier.

>
> And where is it being documented?  What userspace tool needs to be fixed
> up so that the symlink can be removed?

The names are visible in the perf command lines. Perf supports either 
name without changes. So it's not about fixing a specific tool, but 
about using the drivers in both modes, with limited compatibility 
between the two.

Yes probably it needs better documentation.

-Andi