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] [day] [month] [year] [list]
Date:   Mon, 16 Oct 2023 08:48:15 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Mark Rutland <mark.rutland@....com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] driver: perf: arm_pmuv3: Identify 'event->attr.config1'
 based attributes



On 10/13/23 19:17, Mark Rutland wrote:
> On Mon, Oct 09, 2023 at 10:47:53AM +0530, Anshuman Khandual wrote:
>> This defines macros to identify long and rdpmc attributes which get carried
>> inside 'event->attr.config1', thus making the code explicit and clear.
>>
>> Cc: Will Deacon <will@...nel.org>
>> Cc: Mark Rutland <mark.rutland@....com>
>> Cc: linux-arm-kernel@...ts.infradead.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
>> ---
>> This applies on v6.6-rc5.
>>
>>  drivers/perf/arm_pmuv3.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)

I am not sure, if I understand your concerns and/or suggestions properly.

> 
> I think this would make sense to do if we also used a common definition of
> these bits in the helper functions *and* their format attributes, but as-is

Common definitions of sysfs formats ? Which helper - linux/perf/arm_pmuv3.h ?

> this does nothing to relate the two, and I don't think that it improves
> legibility on its own.

Currently armv8pmu_event_is_64bit() and armv8pmu_event_want_user_access()
extracts required values from 'event->attr.config1' with hard coded masks
without any explicit co-relation with PMU_FORMAT_ATTR() described formats
above, unless some one really looks into the config1 bits layout.

Could you please provide some more details on how to go about making this
change better.

> 
> Mark.
> 
>> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
>> index 94723d00548e..797ffd5a8fed 100644
>> --- a/drivers/perf/arm_pmuv3.c
>> +++ b/drivers/perf/arm_pmuv3.c
>> @@ -298,16 +298,19 @@ PMU_FORMAT_ATTR(event, "config:0-15");
>>  PMU_FORMAT_ATTR(long, "config1:0");
>>  PMU_FORMAT_ATTR(rdpmc, "config1:1");
>>  
>> +#define ARM_PMUV3_ATTR_LONG	0x01
>> +#define ARM_PMUV3_ATTR_RDPMC	0x02
>> +
>>  static int sysctl_perf_user_access __read_mostly;
>>  
>>  static inline bool armv8pmu_event_is_64bit(struct perf_event *event)
>>  {
>> -	return event->attr.config1 & 0x1;
>> +	return event->attr.config1 & ARM_PMUV3_ATTR_LONG;
>>  }
>>  
>>  static inline bool armv8pmu_event_want_user_access(struct perf_event *event)
>>  {
>> -	return event->attr.config1 & 0x2;
>> +	return event->attr.config1 & ARM_PMUV3_ATTR_RDPMC;
>>  }
>>  
>>  static struct attribute *armv8_pmuv3_format_attrs[] = {
>> -- 
>> 2.25.1
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ