linux-kernel - Re: [PATCH] x86/irq: Plug vector setup race

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: <20250801145633.2412-1-hogan.wang@huawei.com>
Date: Fri, 1 Aug 2025 22:56:33 +0800
From: Hogan Wang <hogan.wang@...wei.com>
To: <tglx@...utronix.de>, <x86@...nel.org>, <dave.hansen@...ux.intel.com>,
	<kvm@...r.kernel.org>, <alex.williamson@...hat.com>
CC: <weidong.huang@...wei.com>, <yechuan@...wei.com>, <hogan.wang@...wei.com>,
	<wangxinxin.wang@...wei.com>, <jianjay.zhou@...wei.com>,
	<wangjie88@...wei.com>, <maz@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/irq: Plug vector setup race

> On Thu, Jul 24 2025 at 12:49, Thomas Gleixner wrote:
> 

Thank you very much for your professional, friendly, and detailed response.
Based on the clear modification suggestions you provided, I conducted
retesting and validation using the following methods:

1) Start a virtual machine with 192U384G specification, and configure
   one VirtioNet network card and one VirtioSCSI disk.
2) After the virtual machine starts successfully, execute the following
   script inside the virtual machine. The interrupt number 30 is the
   VirtioNet MSI-x interrupt.

for((;;))
    do (for((i=0;i<192;i++))
	    do echo $i > /proc/irq/30/smp_affinity_list
		sleep 0.1
	done)
done

After a 7x24-hour test, no error logs of the type "No irq handler for
vector" were found, I believe this issue should have already been
resolved. 

As you said, this fix cannot solve the problem of lost interrupts.

I believe an effective solution to the issue of lost interrupts
might be to modify the vifo module to avoid un-plug/plug irq,
and instead use a more lightweight method to switch interrupt
modes. Just like:

vfio_irq_handler()
	if kvm_mode
		vfio_send_eventfd(kvm_irq_fd);
	else
		vfio_send_eventfd(qemu_irq_fd);

However, this will bring about some troubles:
1) The kvm_mode variable should be protected, leading to performance loss. 
2) The VFIO interface requires the passing of two eventfds. 
3) Add another interface to implement mode switching. 

Do you have a better solution to fix this interrupt loss issue? 

There is a question that has been troubling me: Why are interrupts
still reported after they have been masked and the interrupt remapping
table entries have been disabled? Is this interrupt cached somewhere?

> Hogan!
> 
> > Hogan reported a vector setup race, which overwrites the interrupt 
> > descriptor in the per CPU vector array resulting in a disfunctional device.
> >
> > CPU0				CPU1
> > 				interrupt is raised in APIC IRR
> > 				but not handled
> >   free_irq()
> >     per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN;
> >
> >   request_irq()			common_interrupt()
> >   				  d = this_cpu_read(vector_irq[vector]);
> >
> >     per_cpu(vector_irq, CPU1)[vector] = desc;
> >
> >     				  if (d == VECTOR_SHUTDOWN)
> > 				    this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
> >
> > free_irq() cannot observe the pending vector in the CPU1 APIC as there 
> > is no way to query the remote CPUs APIC IRR.
> >
> > This requires that request_irq() uses the same vector/CPU as the one 
> > which was freed, but this also can be triggered by a spurious interrupt.
> >
> > Prevent this by reevaluating vector_irq under the vector lock, which 
> > is held by the interrupt activation code when vector_irq is updated.
> 
> Does this fix your problem?

Thanks,

		Hogan
-- 
2.45.1