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: <CAJ9a7Vh44rYWN3mjHPBq8pkBcPuhS2pTBZNaMpWgJECmPZtupg@mail.gmail.com>
Date: Thu, 14 Aug 2025 13:37:23 +0100
From: Mike Leach <mike.leach@...aro.org>
To: James Clark <james.clark@...aro.org>
Cc: Suzuki K Poulose <suzuki.poulose@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jonathan Corbet <corbet@....net>, 
	Leo Yan <leo.yan@....com>, coresight@...ts.linaro.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/6] coresight: Fix holes in struct etmv4_config

Hi James

On Mon, 11 Aug 2025 at 10:32, James Clark <james.clark@...aro.org> wrote:
>
> Lots of u8s are mixed with u64s and u32s so repack it to save a bit
> of space because there's one of these for each ETM.
>
> Signed-off-by: James Clark <james.clark@...aro.org>
> ---
>  drivers/hwtracing/coresight/coresight-etm4x.h | 19 ++++++++++++-------
>  1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> index 746627476bd3..a355a1e9606d 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> @@ -832,28 +832,33 @@ struct etmv4_config {
>         u32                             vipcssctlr;
>         u8                              seq_idx;
>         u8                              syncfreq;
> +       u8                              cntr_idx;
> +       u8                              res_idx;
> +       u8                              ss_idx;
> +       u8                              addr_idx;
> +       u8                              addr_type[ETM_MAX_SINGLE_ADDR_CMP];
> +       u8                              ctxid_idx;
> +       u8                              vmid_idx;
>         u32                             seq_ctrl[ETM_MAX_SEQ_STATES];
>         u32                             seq_rst;
>         u32                             seq_state;
> -       u8                              cntr_idx;
> +
>         u32                             cntrldvr[ETMv4_MAX_CNTR];
>         u32                             cntr_ctrl[ETMv4_MAX_CNTR];
>         u32                             cntr_val[ETMv4_MAX_CNTR];
> -       u8                              res_idx;
> +
>         u32                             res_ctrl[ETM_MAX_RES_SEL];
> -       u8                              ss_idx;
> +
>         u32                             ss_ctrl[ETM_MAX_SS_CMP];
>         u32                             ss_status[ETM_MAX_SS_CMP];
>         u32                             ss_pe_cmp[ETM_MAX_SS_CMP];
> -       u8                              addr_idx;
> +
>         u64                             addr_val[ETM_MAX_SINGLE_ADDR_CMP];
>         u64                             addr_acc[ETM_MAX_SINGLE_ADDR_CMP];
> -       u8                              addr_type[ETM_MAX_SINGLE_ADDR_CMP];

this is 16 x u8 - could this not just stay here?

> -       u8                              ctxid_idx;
> +
>         u64                             ctxid_pid[ETMv4_MAX_CTXID_CMP];
>         u32                             ctxid_mask0;
>         u32                             ctxid_mask1;
> -       u8                              vmid_idx;
>         u64                             vmid_val[ETM_MAX_VMID_CMP];
>         u32                             vmid_mask0;
>         u32                             vmid_mask1;
>
> --
> 2.34.1
>

These attributes have been functionally grouped for ease of
understanding. If we move the _idx values away from what they are
indexing, we probably need comments cross  referencing from where they
where and where they have gone to.

Mike


-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ