linux-kernel - Re: [PATCH v6 1/2] PCI/MSI: Don't disable MSI/MSI-X at shutdown

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]

Date:	Thu, 28 May 2015 18:36:22 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-pci@...r.kernel.org, Fam Zheng <famz@...hat.com>,
	Yinghai Lu <yhlu.kernel.send@...il.com>,
	Yijing Wang <wangyijing@...wei.com>,
	Ulrich Obergfell <uobergfe@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH v6 1/2] PCI/MSI: Don't disable MSI/MSI-X at shutdown

On Thu, May 14, 2015 at 11:53:34AM +0200, Michael S. Tsirkin wrote:
> > you are almost certainly going to subject it to a
> > screaming MSI interrupt and there almost certainly will
> > not be code to disable MSIs as they are disabled by at
> > boot up by default.
> > 
> > Eric
> 
> OTOH if you do disable MSI but leave device functioning you will just
> get screaming INT#x which is even worse because it will end up disabling
> INT#x which is shared, and so breaking multiple devices and not just
> this one.

Eric, can you comment on this please?
To list the points again:
	1- if device is properly shut down there's no need to disable MSIs
	2- if device is not properly shut down disabling MSIs will cause
	   screaming INT#x interrupts
	3- in both cases if we leave MSI on then we can be sure we won't
	   get screaming interrupts since we now disable bus mastering
           which suppresses MSIs (but not INT#x)

Looking at the commit that added the disable, that is d52877c7b1af, you
will see that historically it preceded b566a22c23. So the screaming MSI
problem that d52877c7b1af tried to address is now gone, addressed by
b566a22c23.

What do you think?

> -- 
> MST
--
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/