linux-kernel - Re: [PATCH v3 19/26] coresight: etm4x: Detect access early on the target CPU

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:   Mon, 9 Nov 2020 10:48:47 -0700
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, mike.leach@...aro.org,
        coresight@...ts.linaro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 19/26] coresight: etm4x: Detect access early on the
 target CPU

On Mon, Nov 09, 2020 at 09:48:07AM +0000, Suzuki K Poulose wrote:
> On 11/6/20 8:34 PM, Mathieu Poirier wrote:
> > On Wed, Oct 28, 2020 at 10:09:38PM +0000, Suzuki K Poulose wrote:
> > > In preparation to detect the support for system instruction
> > > support, move the detection of the device access to the target
> > > CPU.
> > > 
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
> > > ---
> > >   .../coresight/coresight-etm4x-core.c          | 45 ++++++++++++++++---
> > >   1 file changed, 40 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > index f038bb10bc78..308674ab746c 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > @@ -56,6 +56,11 @@ static u64 etm4_get_access_type(struct etmv4_config *config);
> > >   static enum cpuhp_state hp_online;
> > > +struct etm_init_arg {
> > 
> > s/etm_init_arg/etm4_init_arg
> 
> Part of the reason was to add a future IP support where it is not all
> ETM4. Again it doesn't really matter. I could change it.
>

I thought about that too but the inclusion of etmv4_drvdata cancels any attempts
at making things generic.
 
> > 
> > > +	struct etmv4_drvdata	*drvdata;
> > > +	struct csdev_access	*csa;
> > > +};
> > > +
> > >   u64 etm4x_sysreg_read(struct csdev_access *csa,
> > >   		      u32 offset,
> > >   		      bool _relaxed,
> > > @@ -669,6 +674,22 @@ static const struct coresight_ops etm4_cs_ops = {
> > >   	.source_ops	= &etm4_source_ops,
> > >   };
> > > +static bool etm_init_iomem_access(struct etmv4_drvdata *drvdata,
> > > +				  struct csdev_access *csa)
> > > +{
> > > +	*csa = CSDEV_ACCESS_IOMEM(drvdata->base);
> > > +	return true;
> > > +}
> > > +
> > > +static bool etm_init_csdev_access(struct etmv4_drvdata *drvdata,
> > > +				  struct csdev_access *csa)
> > > +{
> > > +	if (drvdata->base)
> > > +		return etm_init_iomem_access(drvdata, csa);
> > > +
> > > +	return false;
> > > +}
> > 
> > Returning a boolean rather than an int for the above two functions seems odd to
> > me.
> > 
> 
> We don't return an error from the caller of these functions. So, all we

And this is done from smp_call_function_single() where returning a meaningful
error value would mandate changes to struct etm_init_arg, which is needlessly
messy for this set.  Void my comment. 

> need to know is, if the operation was success or failure. Having bool
> makes it explicit for the checkings, rather than documenting the
> expected return values. Hence the choice. But I am open to changing them
> if you prefer it that way.
> 
> 
> 
> Cheers
> Suzuki