linux-kernel - Re: [PATCH] riscv: Fix irq

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] [day] [month] [year] [list]

Message-ID: <mhng-75fe722b-942d-4184-89d3-1ac2ca7ba9c6@palmer-ri-x1c9>
Date:   Wed, 01 Jun 2022 21:27:23 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     samuel@...lland.org, heiko@...ech.de
CC:     linux-riscv@...ts.infradead.org, samuel@...lland.org,
        aou@...s.berkeley.edu, greentime.hu@...ive.com,
        Paul Walmsley <paul.walmsley@...ive.com>,
        linux-kernel@...r.kernel.org, samuel@...lland.org
Subject:     Re: [PATCH] riscv: Fix irq_work when SMP is disabled

On Tue, 03 May 2022 16:16:26 PDT (-0700), heiko@...ech.de wrote:
> Am Samstag, 30. April 2022, 05:00:23 CEST schrieb Samuel Holland:
>> irq_work is triggered via an IPI, but the IPI infrastructure is not
>> included in uniprocessor kernels. As a result, irq_work never runs.
>> Fall back to the tick-based irq_work implementation on uniprocessor
>> configurations.
>>
>> Fixes: 298447928bb1 ("riscv: Support irq_work via self IPIs")
>> Signed-off-by: Samuel Holland <samuel@...lland.org>
>
> That uniprocessor part seems a tiny bit neglected - as I saw previously
> with alternatives not getting applied as well, so

Ya, it definately is -- and not just me missing this fix, I'd also 
dropped the CONFIG_SMP=n test from my list by accident.  Luckily it 
still boots in QEMU, so at least it's not as brokn as it could be.

>
> Reviewed-by: Heiko Stuebner <heiko@...ech.de>
>
> Though somehow I find the arm32 style a tad nicer by defining
> an is_smp() function [0] that holds the necessary checks.
>
> But I guess that is a style preference.

IIUC that's slightly different: this is a compile-time issue related to 
the IPI framework not coming up at all, not a runtime "are we on a 
uniprocessor" issue.

I put this on for-next (no fixes right now, I'm still collecting 5.19 
merge window material).

Thanks!

>
>
> Heiko
>
>
> [0] https://elixir.bootlin.com/linux/latest/source/arch/arm/include/asm/smp_plat.h#L18
>> ---
>> This was found while bringing up cpufreq on D1. Switching cpufreq
>> governors was hanging on irq_work_sync().
>>
>>  arch/riscv/include/asm/irq_work.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/riscv/include/asm/irq_work.h b/arch/riscv/include/asm/irq_work.h
>> index d6c277992f76..b53891964ae0 100644
>> --- a/arch/riscv/include/asm/irq_work.h
>> +++ b/arch/riscv/include/asm/irq_work.h
>> @@ -4,7 +4,7 @@
>>
>>  static inline bool arch_irq_work_has_interrupt(void)
>>  {
>> -	return true;
>> +	return IS_ENABLED(CONFIG_SMP);
>>  }
>>  extern void arch_irq_work_raise(void);
>>  #endif /* _ASM_RISCV_IRQ_WORK_H */
>>