linux-kernel - Re: [PATCH v2 03/17] coresight: trbe: Add a helper to calculate the trace generated

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, 1 Oct 2021 09:36:24 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        maz@...nel.org, catalin.marinas@....com, mark.rutland@....com,
        james.morse@....com, anshuman.khandual@....com, leo.yan@...aro.org,
        mike.leach@...aro.org, will@...nel.org, lcherian@...vell.com,
        coresight@...ts.linaro.org
Subject: Re: [PATCH v2 03/17] coresight: trbe: Add a helper to calculate the
 trace generated

On 30/09/2021 18:54, Mathieu Poirier wrote:
> Hi Suzuki,
> 
> On Tue, Sep 21, 2021 at 02:41:07PM +0100, Suzuki K Poulose wrote:
>> We collect the trace from the TRBE on FILL event from IRQ context
>> and when via update_buffer(), when the event is stopped. Let us
> 
> s/"and when via"/"and via"
> 
>> consolidate how we calculate the trace generated into a helper.
>>
>> Cc: Mathieu Poirier <mathieu.poirier@...aro.org>
>> Cc: Mike Leach <mike.leach@...aro.org>
>> Cc: Leo Yan <leo.yan@...aro.org>
>> Reviewed-by: Anshuman Khandual <anshuman.khandual@....com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>> ---
>>   drivers/hwtracing/coresight/coresight-trbe.c | 48 ++++++++++++--------
>>   1 file changed, 30 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
>> index 63f7edd5fd1f..063c4505a203 100644
>> --- a/drivers/hwtracing/coresight/coresight-trbe.c
>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
>> @@ -527,6 +527,30 @@ static enum trbe_fault_action trbe_get_fault_act(u64 trbsr)
>>   	return TRBE_FAULT_ACT_SPURIOUS;
>>   }
>>   
>> +static unsigned long trbe_get_trace_size(struct perf_output_handle *handle,
>> +					 struct trbe_buf *buf,
>> +					 bool wrap)
> 
> Stacking
> 

Ack

>> +{
>> +	u64 write;
>> +	u64 start_off, end_off;
>> +
>> +	/*
>> +	 * If the TRBE has wrapped around the write pointer has
>> +	 * wrapped and should be treated as limit.
>> +	 */
>> +	if (wrap)
>> +		write = get_trbe_limit_pointer();
>> +	else
>> +		write = get_trbe_write_pointer();
>> +
>> +	end_off = write - buf->trbe_base;
> 
> In both arm_trbe_alloc_buffer() and trbe_handle_overflow() the base address is
> acquired using get_trbe_base_pointer() but here it is referenced directly - any
> reason for that?  It certainly makes reviewing this simple patch quite
> difficult because I keep wondering if I am missing something subtle...

Very good observation. So far, we always prgrammed the TRBBASER with the
the VA(ring_buffer[0]). And thus reading the BASER and using the 
buf->trbe_base is all fine.

But going forward, we are going to use different values for the TRBBASER
to work around erratum. Thus to make the computation of the "offsets"
within the ring buffer, it is always correct to use this field. I could
move this to the patch where the work around is introduced, and put in
a comment there.

Thanks for the review

Suzuki