linux-kernel - Masked MSIs expectations

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

Message-ID: <1368086982.25488.165.camel@pasglop>
Date:	Thu, 09 May 2013 18:09:42 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	linux-pci@...r.kernel.org
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Joerg Roedel <joro@...tes.org>
Subject: Masked MSIs expectations

Hi folks !

Do we provide drivers any guarantee to what happen if an MSI is shot
while masked with disable_irq() or while not yet request_irq()'ed ?

Do we guarantee delivery (latched while masked), non-delivery, or
undefined ?

I'm bringing up a piece of HW where if it happened, it won't be
automatically sent to the CPU and can block further MSIs unless I
explicitly either ditch it or force a resend when unmasking (at the PCI
Express controller PIC level).

I'm tempted to just ditch anything that happened while masked, it would
make everything easier on my side, but maybe drivers have different
expectations (and of course an LSI would still shoot, that's not an
issue, only MSIs are in question here).

I have cases of devices continuing to shoot one or two MSIs after kexec
and before the new kernel takes over, causing a "loss" of any subsequent
one unless I deal with that case one way or another.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/