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]
Message-ID: <20150528182645-mutt-send-email-mst@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ