linux-kernel - Re: [patch 2/4] genirq: Move irq_wait_for

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: <b97f4d0d-ddb6-4fca-bf96-e9f11e00e060@kernel.org>
Date: Tue, 22 Jul 2025 09:07:37 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>
Cc: Liangyan <liangyan.peng@...edance.com>,
 Yicong Shen <shenyicong.1023@...edance.com>
Subject: Re: [patch 2/4] genirq: Move irq_wait_for_poll() to call site

On 18. 07. 25, 20:54, Thomas Gleixner wrote:
> Move it to the call site so that the waiting for the INPROGRESS flag can be
> reused by an upcoming mitigation for a potential live lock in the edge type
> handler.
> 
> No functional change.

Reviewed-by: Jiri Slaby <jirislaby@...nel.org>

> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -449,11 +449,19 @@ void unmask_threaded_irq(struct irq_desc
>   	unmask_irq(desc);
>   }
>   
> -static bool irq_check_poll(struct irq_desc *desc)
> +/* Busy wait until INPROGRESS is cleared */
> +static bool irq_wait_on_inprogress(struct irq_desc *desc)
>   {
> -	if (!(desc->istate & IRQS_POLL_INPROGRESS))
> -		return false;
> -	return irq_wait_for_poll(desc);
> +	if (IS_ENABLED(CONFIG_SMP)) {
> +		do {
> +			raw_spin_unlock(&desc->lock);
> +			while (irqd_irq_inprogress(&desc->irq_data))
> +				cpu_relax();
> +			raw_spin_lock(&desc->lock);
> +		} while (irqd_irq_inprogress(&desc->irq_data));
> +	}
> +	/* Might have been disabled in meantime */
> +	return !irqd_irq_disabled(&desc->irq_data) && desc->action;

Just noting that this line is newly evaluated on !SMP too. But it is 
still supposed to evaluate to false, given we are here on this only CPU.

thanks,
-- 
js
suse labs