linux-kernel - Re: [PATCH -fixes] riscv: kexec: Avoid deadlock in kexec crash path

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: <0e34cd12-66d8-4432-780a-f08d03a2c95e@sifive.com>
Date: Wed, 27 Mar 2024 07:36:45 -0700 (PDT)
From: Paul Walmsley <paul.walmsley@...ive.com>
To: Song Shuai <songshuaishuai@...ylab.org>
cc: palmer@...belt.com, aou@...s.berkeley.edu, guoren@...nel.org, 
    xianting.tian@...ux.alibaba.com, takahiro.akashi@...aro.org, 
    linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -fixes] riscv: kexec: Avoid deadlock in kexec crash
 path

Hi Song Shuai, 

On Fri, 8 Dec 2023, Song Shuai wrote:

> If the kexec crash code is called in the interrupt context, the
> machine_kexec_mask_interrupts() function will trigger a deadlock while
> trying to acquire the irqdesc spinlock and then deacitive irqchip.
> 
> To avoid the deadlock, this patch directly EOI the irq regardless of
> the active status of irqchip.

Taking a quick look at the other architectures, looks like no one else is 
doing this.  Is this addressing a RISC-V-only problem?

> diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
> index f6c7135b00d7..d7ddf4d2b243 100644
> --- a/arch/riscv/kernel/machine_kexec.c
> +++ b/arch/riscv/kernel/machine_kexec.c
> @@ -149,20 +149,12 @@ static void machine_kexec_mask_interrupts(void)
>  
>  	for_each_irq_desc(i, desc) {
>  		struct irq_chip *chip;
> -		int ret;
>  
>  		chip = irq_desc_get_chip(desc);
>  		if (!chip)
>  			continue;
>  
> -		/*
> -		 * First try to remove the active state. If this
> -		 * fails, try to EOI the interrupt.
> -		 */
> -		ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
> -
> -		if (ret && irqd_irq_inprogress(&desc->irq_data) &&
> -		    chip->irq_eoi)
> +		if (chip->irq_eoi && irqd_irq_inprogress(&desc->irq_data))
>  			chip->irq_eoi(&desc->irq_data);


- Paul