linux-kernel - Re: [PATCH v8 3/9] perf/amd/iommu: Misc fix up perf_iommu

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: <39fa57a2-7667-a8e4-6ae1-fc90f3b11d82@amd.com>
Date:   Tue, 7 Feb 2017 11:50:27 +0700
From:   Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     <linux-kernel@...r.kernel.org>, <iommu@...ts.linux-foundation.org>,
        <joro@...tes.org>, <bp@...en8.de>, <mingo@...hat.com>
Subject: Re: [PATCH v8 3/9] perf/amd/iommu: Misc fix up perf_iommu_read

Peter,

On 1/23/17 19:33, Peter Zijlstra wrote:
> On Mon, Jan 16, 2017 at 01:23:30AM -0600, Suravee Suthikulpanit wrote:
>>  static void perf_iommu_read(struct perf_event *event)
>>  {
>> -	u64 count = 0ULL;
>> -	u64 prev_raw_count = 0ULL;
>> -	u64 delta = 0ULL;
>> +	u64 count, prev;
>> +	s64 delta;
>
> I did send that email where I told I was mistaken with that suggestion,
> right? Since the counter always increments (it does, right), a negative
> delta does not make sense.

Right, I sent this out before your reply email in V7. I'll change the delta
back to u64. I'll fix this in V9.

>
>>  	struct hw_perf_event *hwc = &event->hw;
>>
>>  	amd_iommu_pc_get_set_reg_val(_GET_DEVID(event),
>> @@ -330,18 +329,20 @@ static void perf_iommu_read(struct perf_event *event)
>>  				IOMMU_PC_COUNTER_REG, &count, false);
>>
>>  	/* IOMMU pc counter register is only 48 bits */
>> -	count &= 0xFFFFFFFFFFFFULL;
>> +	count &= GENMASK_ULL(48, 0);
>
> Why do you need that at all? If the counter is only 48 bits, what does
> the hardware do with the upper bits?

So, bit 48-63 are reserved. I just try to ensure that the HW does not use them
for anything (also probably in the future).

>>
>> -	prev_raw_count =  local64_read(&hwc->prev_count);
>> -	if (local64_cmpxchg(&hwc->prev_count, prev_raw_count,
>> -					count) != prev_raw_count)
>> -		return;
>> +	prev = local64_read(&hwc->prev_count);
>
> I'm still not convinced you can do away with that cmpxchg.

Ok, I can just leave the local64_read() in.

Thanks,
Suravee