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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 1 Oct 2021 09:15:35 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
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 Fri, Oct 01, 2021 at 09:36:24AM +0100, Suzuki K Poulose wrote:
> 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.

That will be greatly appreciated.

> 
> Thanks for the review
> 
> Suzuki
> 

Powered by blists - more mailing lists