linux-kernel - Re: [PATCH] irqchip/sifive-plic: use hartid as context

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]

Message-ID: <aPbeb1SEZr7CG2eN@kernel.org>
Date: Tue, 21 Oct 2025 09:14:23 +0800
From: Troy Mitchell <troy.mitchell@...ux.dev>
To: Thomas Gleixner <tglx@...utronix.de>,
	Troy Mitchell <troy.mitchell@...ux.dev>,
	Paul Walmsley <pjw@...nel.org>,
	Samuel Holland <samuel.holland@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>
Cc: linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] irqchip/sifive-plic: use hartid as context_id in OF to
 fix AMP conflicts

On Mon, Oct 20, 2025 at 07:44:55PM +0200, Thomas Gleixner wrote:
> On Mon, Oct 20 2025 at 11:49, Troy Mitchell wrote:
> > In asymmetric multi-processing (AMP) scenarios, the original PLIC
> > driver used the context loop index 'i' as context_id for OF (device
> 
> Which original driver and when did it stop to use the context loop index?
> 
> > tree) platforms. This caused multiple contexts from different harts
> > (e.g., core0 and core4) to share the same enable_base, leading to
> > conflicts when initializing the PLIC.
> 
> When did it stop to cause the issues? And if the issues have been
> already resolved, what is this patch about?
The issue still exists in the current driver.
The PLIC driver for OF-based platforms assigns context_id = i inside
the context loop, which assumes that all harts are numbered contiguously
starting from 0.

In AMP systems (e.g., when Linux boots from hart4 while hart0 runs another OS),
this assumption breaks — multiple contexts from different clusters share the same
enable_base(e.g., core4's enable_base = core0's enable_base), causing conflicts.

This patch fixes the problem by assigning context_id based on the actual hartid,
ensuring that each hart context maps to a unique enable region,
while preserving behavior on SMP and UP systems.

Does it make sense? I'll update my commit message in the next version.
> 
> > This patch resolves enable_base conflicts on AMP platforms while
> 
> # git grep 'This patch' Documentation/process/
> 
> > maintaining SMP/UP behavior.
> 
> There is zero explanation what this patch does to resolve the issue.
> 
> See also:
> 
>   https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog
Thanks for your link!
> 
> >  
> >  		if (is_of_node(fwnode)) {
> > -			context_id = i;
> > +			context_id = hartid * 2 + i % 2;
> 
> This is incomprehensible and will cause head scratching 6 weeks down the
> road. This needs a proper comment with an explanation what this is
> about and why it is correct under all circumstances.
I will add comments here. Thanks!

                        - Troy
> 
> Thanks,
> 
>         tglx