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: <9f36bedd-1a68-43a9-826d-ce56caf01c52@arm.com>
Date: Tue, 16 Apr 2024 15:03:52 -0500
From: Jeremy Linton <jeremy.linton@....com>
To: Yunhui Cui <cuiyunhui@...edance.com>, rafael@...nel.org, lenb@...nel.org,
 linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
 paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
 linux-riscv@...ts.infradead.org, bhelgaas@...gle.com, james.morse@....com,
 jhugo@...eaurora.org, john.garry@...wei.com, Jonathan.Cameron@...wei.com,
 pierre.gondois@....com, sudeep.holla@....com, tiantao6@...wei.com
Subject: Re: [PATCH v3 2/3] riscv: cacheinfo: initialize cacheinfo's level and
 type from ACPI PPTT

Hi,


On 4/15/24 22:14, Yunhui Cui wrote:
> Before cacheinfo can be built correctly, we need to initialize level
> and type. Since RSIC-V currently does not have a register group that
> describes cache-related attributes like ARM64, we cannot obtain them
> directly, so now we obtain cache leaves from the ACPI PPTT table
> (acpi_get_cache_info()) and set the cache type through split_levels.
> 
> Suggested-by: Jeremy Linton <jeremy.linton@....com>
> Suggested-by: Sudeep Holla <sudeep.holla@....com>
> Signed-off-by: Yunhui Cui <cuiyunhui@...edance.com>
> ---
>   arch/riscv/kernel/cacheinfo.c | 20 ++++++++++++++++++++
>   1 file changed, 20 insertions(+)
> 
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index 30a6878287ad..dc5fb70362f1 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -6,6 +6,7 @@
>   #include <linux/cpu.h>
>   #include <linux/of.h>
>   #include <asm/cacheinfo.h>
> +#include <linux/acpi.h>
>   
>   static struct riscv_cacheinfo_ops *rv_cache_ops;
>   
> @@ -78,6 +79,25 @@ int populate_cache_leaves(unsigned int cpu)
>   	struct device_node *prev = NULL;
>   	int levels = 1, level = 1;
>   
> +	if (!acpi_disabled) {
> +		int ret, idx, fw_levels, split_levels;
> +
> +		ret = acpi_get_cache_info(cpu, &fw_levels, &split_levels);
> +		if (ret)
> +			return ret;
> +
> +		for (idx = 0; level <= this_cpu_ci->num_levels &&
> +		     idx < this_cpu_ci->num_leaves; idx++, level++) {

AFAIK the purpose of idx here it to assure that the number of cache 
leaves is not overflowing. But right below we are utilizing two of them 
at once, so this check isn't correct. OTOH, since its allocated as 
levels + split_levels I don't think its actually possible for this to 
cause a problem. Might be worthwhile to just hoist it before the loop 
and revalidate the total leaves about to be utilized.


> +			if (level <= split_levels) {
> +				ci_leaf_init(this_leaf++, CACHE_TYPE_DATA, level);
> +				ci_leaf_init(this_leaf++, CACHE_TYPE_INST, level);
> +			} else {
> +				ci_leaf_init(this_leaf++, CACHE_TYPE_UNIFIED, level);
> +			}
> +		}
> +		return 0;
> +	}
> +
>   	if (of_property_read_bool(np, "cache-size"))
>   		ci_leaf_init(this_leaf++, CACHE_TYPE_UNIFIED, level);
>   	if (of_property_read_bool(np, "i-cache-size"))


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ