| 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
| ||
|
Message-ID: <20250801093201232CYacRrFIHaDJWsjc3rbNz@zte.com.cn>
Date: Fri, 1 Aug 2025 09:32:01 +0800 (CST)
From: <liu.xuemei1@....com.cn>
To: <alex@...ti.fr>, <paul.walmsley@...ive.com>
Cc: <palmer@...belt.com>, <aou@...s.berkeley.edu>, <spersvold@...il.com>,
<sudeep.holla@....com>, <mikisabate@...il.com>, <robh@...nel.org>,
<liu.xuemei1@....com.cn>, <linux-riscv@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] riscv: cacheinfo: init cache levels via fetch_cache_info when SMP disabled
On 7/31/25 21:29, alex@...ti.fr wrote:
> > From: Jessica Liu <liu.xuemei1@....com.cn>
> >
> > As described in commit 1845d381f280 ("riscv: cacheinfo: Add back
> > init_cache_level() function"), when CONFIG_SMP is undefined, the cache
> > hierarchy detection needs to be performed through the init_cache_level(),
> > whereas when CONFIG_SMP is defined, this detection is handled during the
> > init_cpu_topology() process.
> >
> > Furthermore, while commit 66381d36771e ("RISC-V: Select ACPI PPTT drivers")
> > enables cache information retrieval through the ACPI PPTT table, the
> > init_of_cache_level() called within init_cache_level() cannot support cache
> > hierarchy detection through ACPI PPTT. Therefore, when CONFIG_SMP is
> > undefined, we directly invoke the fetch_cache_info function to initialize
> > the cache levels.
> >
> > Signed-off-by: Jessica Liu <liu.xuemei1@....com.cn>
> > ---
> > arch/riscv/kernel/cacheinfo.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> > index 26b085dbdd07..f81ca963d177 100644
> > --- a/arch/riscv/kernel/cacheinfo.c
> > +++ b/arch/riscv/kernel/cacheinfo.c
> > @@ -73,7 +73,11 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
> >
> > int init_cache_level(unsigned int cpu)
> > {
> > - return init_of_cache_level(cpu);
> > +#ifdef CONFIG_SMP
> > + return 0;
> > +#endif
> > +
> > + return fetch_cache_info(cpu);
> > }
> >
> > int populate_cache_leaves(unsigned int cpu)
>
>
> Is the current behaviour wrong or just redundant? If wrong, I'll add a
> Fixes tag to backport, otherwise I won't.
>
> Thanks,
>
> Alex
Hi Alex,
The current behavior is actually wrong when using ACPI on !CONFIG_SMP
systems. The original init_of_cache_level() cannot detect cache hierarchy
through ACPI PPTT table, which means cache information would be missing
in this configuration.
The patch fixes this by directly calling fetch_cache_info() when
CONFIG_SMP is undefined, which properly handles both DT and ACPI cases.
So yes, it would be appropriate to add a Fixes tag. The commit being
fixed is 1845d381f280 ("riscv: cacheinfo: Add back init_cache_level() function").
Please let me know if you need any additional information.
Best regards,
Jessica
<div class="zcontentRow"><p>On 7/31/25 21:29, alex@...ti.fr wrote:</p><p>> > From: Jessica Liu <liu.xuemei1@....com.cn></p><p>> ></p><p>> > As described in commit 1845d381f280 ("riscv: cacheinfo: Add back</p><p>> > init_cache_level() function"), when CONFIG_SMP is undefined, the cache</p><p>> > hierarchy detection needs to be performed through the init_cache_level(),</p><p>> > whereas when CONFIG_SMP is defined, this detection is handled during the</p><p>> > init_cpu_topology() process.</p><p>> ></p><p>> > Furthermore, while commit 66381d36771e ("RISC-V: Select ACPI PPTT drivers")</p><p>> > enables cache information retrieval through the ACPI PPTT table, the</p><p>> > init_of_cache_level() called within init_cache_level() cannot support cache</p><p>> > hierarchy detection through ACPI PPTT. Therefore, when CONFIG_SMP is</p><p>> > undefined, we directly invoke the fetch_cache_info function to initialize</p><p>> > the cache levels.</p><p>> ></p><p>> > Signed-off-by: Jessica Liu <liu.xuemei1@....com.cn></p><p>> > ---</p><p>> > arch/riscv/kernel/cacheinfo.c | 6 +++++-</p><p>> > 1 file changed, 5 insertions(+), 1 deletion(-)</p><p>> ></p><p>> > diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c</p><p>> > index 26b085dbdd07..f81ca963d177 100644</p><p>> > --- a/arch/riscv/kernel/cacheinfo.c</p><p>> > +++ b/arch/riscv/kernel/cacheinfo.c</p><p>> > @@ -73,7 +73,11 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,</p><p>> ></p><p>> > int init_cache_level(unsigned int cpu)</p><p>> > {</p><p>> > - return init_of_cache_level(cpu);</p><p>> > +#ifdef CONFIG_SMP</p><p>> > + return 0;</p><p>> > +#endif</p><p>> > +</p><p>> > + return fetch_cache_info(cpu);</p><p>> > }</p><p>> ></p><p>> > int populate_cache_leaves(unsigned int cpu)</p><p>> </p><p>> </p><p>> Is the current behaviour wrong or just redundant? If wrong, I'll add a </p><p>> Fixes tag to backport, otherwise I won't.</p><p>> </p><p>> Thanks,</p><p>> </p><p>> Alex</p><p><br></p><p>Hi Alex,</p><p><br></p><p>The current behavior is actually wrong when using ACPI on !CONFIG_SMP</p><p>systems. The original init_of_cache_level() cannot detect cache hierarchy</p><p>through ACPI PPTT table, which means cache information would be missing</p><p>in this configuration.</p><p><br></p><p>The patch fixes this by directly calling fetch_cache_info() when</p><p>CONFIG_SMP is undefined, which properly handles both DT and ACPI cases.</p><p><br></p><p>So yes, it would be appropriate to add a Fixes tag. The commit being</p><p>fixed is 1845d381f280 ("riscv: cacheinfo: Add back init_cache_level() function").</p><p><br></p><p>Please let me know if you need any additional information.</p><p><br></p><p>Best regards,</p><p>Jessica</p><p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br></p><p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br></p><p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br></p><p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br></p><p><br></p></div>
Powered by blists - more mailing lists