linux-kernel - Re: [PATCH 2/2] perf/arm-cmn: Add sysfs identifier

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: <570d8563-6e28-8d11-2d3c-83cbda9ac4a3@arm.com>
Date:   Wed, 14 Jun 2023 18:29:55 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     John Garry <john.g.garry@...cle.com>, will@...nel.org
Cc:     mark.rutland@....com, ilkka@...amperecomputing.com,
        renyu.zj@...ux.alibaba.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] perf/arm-cmn: Add sysfs identifier

On 2023-06-14 15:55, John Garry wrote:
> On 12/06/2023 18:16, Robin Murphy wrote:
>> Expose a sysfs identifier encapsulating the CMN part number and revision
>> so that jevents can narrow down a fundamental set of possible events for
>> calculating metrics. Configuration-dependent aspects - such as whether a
>> given node type is present, and/or a given node ID is valid - are still
>> not covered, and in general it's hard to see how userspace could handle
>> them, so we won't be removing any data or validation logic from the
>> driver any time soon, but at least it's a step in a useful direction.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@....com>
> 
> FWIW, Reviewed-by:
> John Garry <john.g.garry@...cle.com>
> 
> However a comment, below.
> 
>> ---
>>   drivers/perf/arm-cmn.c | 20 ++++++++++++++++----
>>   1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
>> index 8cf4ed932950..088dc5c690a4 100644
>> --- a/drivers/perf/arm-cmn.c
>> +++ b/drivers/perf/arm-cmn.c
>> @@ -1199,19 +1199,31 @@ static ssize_t arm_cmn_cpumask_show(struct 
>> device *dev,
>>   static struct device_attribute arm_cmn_cpumask_attr =
>>           __ATTR(cpumask, 0444, arm_cmn_cpumask_show, NULL);
>> -static struct attribute *arm_cmn_cpumask_attrs[] = {
>> +static ssize_t arm_cmn_identifier_show(struct device *dev,
>> +                       struct device_attribute *attr, char *buf)
>> +{
>> +    struct arm_cmn *cmn = to_cmn(dev_get_drvdata(dev));
>> +
>> +    return sysfs_emit(buf, "%03x%02x\n", cmn->part, cmn->rev);
> 
> I don't think that this gives the "0x" prefix, right? It is just an 
> encoded string of values, so not strictly necessary or even appropriate, 
> I suppose.

Indeed that was deliberate, to emphasise that this is still a string (of 
hex digits), not a single numeric value.

> However, if userspace wants to improve scalability by, say, matching an 
> event for all revs of a model, userspace (perf tool) needs to be 
> programmed in the JSONs somehow since we have no delimiter.

FWIW I don't mind the original idea of prefix-based string matching - it 
feels like about the right level of compromise to give a sufficient 
degree of expressiveness without having to go as far as inventing some 
whole crazy expression syntax for interpreting values - so all I've 
really done here vs. Jing's patch is streamline the string itself. I'm 
still assuming the same general usage model, such that a hypothetical 
JSON encoding of, say, the hnf_snp_sent_cluster event could have:

	"Compat": {"43603","43c??"} /* CMN-650 r2p0, all CMN-700 */

(array and explicit wildcard syntax made up for the sake of implied 
debate - not sure if I have a particular preference either way)

If we assume that over time, events are more likely to be added and 
stick around than to be removed, then what might be handy would be the 
additional notion of something like a "CompatExcept" property to 
describe negative matches. That could definitely scale better for the 
NOT_CMN600 and CMN_650ON cases in the current driver logic. Then what 
would also be really cool would be the ability to define events 
hierarchically based on other aliases - e.g. the driver could just 
expose a general "sbsx" sysfs alias as "type=5,eventid=?" if SBSX nodes 
are present, then the detailed events like "sbsx_rd_req" are somehow 
encoded in JSON as the equivalent of "sbsx,eventid=1" such that they're 
hidden if not relevant - at which point I think I could actually punt 
all the fiddly bits out of driver code into JSON :D

Cheers,
Robin.