diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-07-24 10:34:24 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-07-27 12:43:59 -0700 |
| commit | 681fb81a41711f1237899a2e24001d9b5d5efae4 (patch) | |
| tree | 34a1388b0312724d6f90222ae730a891678b2bca /scripts/git.orderFile | |
| parent | 0c5fb7bc6177b8903196dcb3f4b211d51bbd0ae6 (diff) | |
| download | linux-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
