linux-kernel - Re: [PATCH v9 1/7] RISC-V: Clear SIP bit only when using SBI IPI operations

Open Source and information security mailing list archives

Message-Id: <6ABE254E-C7DA-468B-9A6B-D10FF32E0E89@jrtc27.com>
Date:   Sat, 3 Sep 2022 21:16:14 +0100
From:   Jessica Clarke <jrtc27@...c27.com>
To:     Anup Patel <apatel@...tanamicro.com>
Cc:     Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Atish Patra <atishp@...shpatra.org>,
        Alistair Francis <Alistair.Francis@....com>,
        Anup Patel <anup@...infault.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        linux-kernel@...r.kernel.org, Bin Meng <bmeng.cn@...il.com>
Subject: Re: [PATCH v9 1/7] RISC-V: Clear SIP bit only when using SBI IPI
 operations

]On 3 Sept 2022, at 17:13, Anup Patel <apatel@...tanamicro.com> wrote:
> 
> The software interrupt pending (i.e. [M|S]SIP) bit is writeable for
> S-mode but read-only for M-mode so we clear this bit only when using
> SBI IPI operations.

Uh, where is this specified? I don’t see that, and that would be odd.
The spec clearly says that if supervisor software interrupts are
implemented then the bit is writeable, with no caveats on when (beyond
the permissions required to access the CSR in general).

This patch does make sense for a different reason though: that IPIs may
not be using software interrupts at all (in the IMSIC case).

Jess

> Signed-off-by: Anup Patel <apatel@...tanamicro.com>
> Reviewed-by: Bin Meng <bmeng.cn@...il.com>
> ---
> arch/riscv/kernel/sbi.c | 8 +++++++-
> arch/riscv/kernel/smp.c | 2 --
> 2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
> index 775d3322b422..fc614650a2e3 100644
> --- a/arch/riscv/kernel/sbi.c
> +++ b/arch/riscv/kernel/sbi.c
> @@ -643,8 +643,14 @@ static void sbi_send_cpumask_ipi(const struct cpumask *target)
> 	sbi_send_ipi(target);
> }
> 
> +static void sbi_ipi_clear(void)
> +{
> +	csr_clear(CSR_IP, IE_SIE);
> +}
> +
> static const struct riscv_ipi_ops sbi_ipi_ops = {
> -	.ipi_inject = sbi_send_cpumask_ipi
> +	.ipi_inject = sbi_send_cpumask_ipi,
> +	.ipi_clear = sbi_ipi_clear
> };
> 
> void __init sbi_init(void)
> diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
> index 760a64518c58..c56d67f53ea9 100644
> --- a/arch/riscv/kernel/smp.c
> +++ b/arch/riscv/kernel/smp.c
> @@ -83,8 +83,6 @@ void riscv_clear_ipi(void)
> {
> 	if (ipi_ops && ipi_ops->ipi_clear)
> 		ipi_ops->ipi_clear();
> -
> -	csr_clear(CSR_IP, IE_SIE);
> }
> EXPORT_SYMBOL_GPL(riscv_clear_ipi);
> 
> -- 
> 2.34.1
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

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