linux-kernel - Firing an interrupt pin induces the occurrence of another interrupt

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>] [day] [month] [year] [list]

Message-ID: <DM6PR04MB6249DDAA6BCD01D1B37D41E8C3C80@DM6PR04MB6249.namprd04.prod.outlook.com>
Date:   Thu, 18 Jul 2019 03:48:42 +0000
From:   Kar Hin Ong <kar.hin.ong@...com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     Keng Soon Cheah <keng.soon.cheah@...com>
Subject: Firing an interrupt pin induces the occurrence of another interrupt

Hi, 

I have a x86 system with Xeon CPU running Linux with preempt_rt patch (kernel version 4.14). 

When a PCI device firing interrupt to GSI 44 (ioapic2, pin20), I noticed that GSI 19 (ioapic1, pin19) will get fired as well, and then it went unhandled.
I can reproduce this issue by using another PCI card or swapping the PCI card to other slot, as long as the device is driving GSI 44.

By putting traces on do_IRQ, I can see it's being called once for GSI 44, then being called another once for GSI 19.

I tried to reproduce it on RHEL 8, it is not reproducible initially. However, after I added "threadirqs" kernel parameter, this behaviour appears on RHEL 8 as well.

I would like to get your advice on whether this could be a kernel issue or hardware issue.
Inputs on how to further narrow down the issue are most welcomed.

Thanks very much in advance,
Kar Hin Ong