summaryrefslogtreecommitdiff
path: root/scripts/git.orderFile
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2026-07-24 10:34:24 -0700
committerSean Christopherson <seanjc@google.com>2026-07-27 12:43:59 -0700
commit681fb81a41711f1237899a2e24001d9b5d5efae4 (patch)
tree34a1388b0312724d6f90222ae730a891678b2bca /scripts/git.orderFile
parent0c5fb7bc6177b8903196dcb3f4b211d51bbd0ae6 (diff)
downloadlinux-681fb81a41711f1237899a2e24001d9b5d5efae4.tar.gz
linux-681fb81a41711f1237899a2e24001d9b5d5efae4.zip
KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC
When getting a to-be-injected IRQ, don't WARN if the IRQ disappeared and the VM has an in-kernel PIC, as the ExtINT handling that's routed through KVM's virtual PIC is tracked per-VM, not per-vCPU. If another vCPU grabs the IRQ, or deasserts the interrupt (which is level-triggered), then it's both expected and "fine" for a Keep the assert for split IRQCHIP VMs to help detect KVM bugs, as userspace is responsible for routing ExtINT to the intended vCPU, i.e. once an ExtINT is pending, it can't be cleared without holding the vCPU's mutex, and thus false positives are impossible. Fixes: bf672720e83c ("KVM: x86: check the kvm_cpu_get_interrupt result before using it") Debugged-by: Alexander Potapenko <glider@google.com> Reported-by: syzbot+dd769db18693736eee89@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89 Closes: https://lore.kernel.org/all/6a360fdf.871e809a.2d6dda.0000.GAE@google.com Link: https://patch.msgid.link/20260724173425.278753-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'scripts/git.orderFile')
0 files changed, 0 insertions, 0 deletions