public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Khalid Aziz <khalid.aziz@hp.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org, bhelgaas@google.com,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH] Disable Bus Master on PCI device shutdown
Date: Thu, 07 Jun 2012 11:43:44 -0600	[thread overview]
Message-ID: <1339091024.25761.896.camel@lyra> (raw)
In-Reply-To: <20120606200946.GA11946@srcf.ucam.org>

On Wed, 2012-06-06 at 21:09 +0100, Matthew Garrett wrote:
> On Wed, Jun 06, 2012 at 12:42:07PM -0700, Eric W. Biederman wrote:
> 
> > pci_device_shutdown calls drv->shutdown before calling
> > pci_device_disable.  Which means that only devices that have trouble
> > with this bit being flipped while DMA is ongoing and don't bother
> > to stop their own DMA will have a problem.
> 
> drv->shutdown should already be quiescing the hardware. If it isn't, it 
> should be. If it is, what does this patch fix? Many drivers 
> call pci_enable_device() early enough that they clearly expect the 
> hardware to be quiescent when they do so, so this really does seem to 
> simply handle the kexec case without handling any other cases that could 
> be similarly problematic.                               
> 

I agree drv->shutdown should quiesce the hardware (although anecdotal
evidence suggests that is not happening), so turning Bus Master bit off
is an additional safety measure. As Alan pointed out, doing that can be
fraught with danger. Clearing Bus Master bit seems like the right thing
to do, but due to buggy hardware/firmware it can cause problems,
although those problems happen at predictable times and thus become
easier to diagnose.

I am considering other options. Andi mentioned command line option which
does allow for some control instead of blindly clearing Bus Master bit
on all system. I am also wondering if clearing Bus Master bit on just
the PCI bridges is an option. If Bus Master bit is clear on a bridge, it
is not supposed to allow DMA transactions through it. That can prevent
random memory corruption by broken devices and also not upset the
devices that do not like their Bus Master bit cleared. Any opinions on
this option?

I have also acquired a broadcom NIC that is causing what looks like
random DMAs into kernel memory on a kexec, although this is with a
kernel that does not have the Bus Master reset patch. I will run some
experiments on this NIC and see what I can figure out.

====================================================================
Khalid Aziz                                         Unix Systems Lab
(970)898-9214                                        Hewlett-Packard
khalid.aziz@hp.com                                  Fort Collins, CO


  reply	other threads:[~2012-06-07 17:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-27 19:00 [PATCH] Disable Bus Master on PCI device shutdown Khalid Aziz
2012-05-03 23:52 ` Bjorn Helgaas
2012-05-04 17:15   ` Bjorn Helgaas
2012-06-06 13:50 ` Matthew Garrett
2012-06-06 16:17   ` Khalid Aziz
2012-06-06 16:27     ` Matthew Garrett
2012-06-06 17:32       ` Khalid Aziz
2012-06-06 17:42         ` Matthew Garrett
2012-06-06 18:07           ` Khalid Aziz
2012-06-06 19:42             ` Eric W. Biederman
2012-06-06 20:09               ` Matthew Garrett
2012-06-07 17:43                 ` Khalid Aziz [this message]
2012-06-07 14:21               ` Khalid Aziz
2012-06-06 20:16             ` Myron Stowe
2012-06-06 23:03               ` Khalid Aziz
2012-06-06 23:18                 ` Myron Stowe
2012-06-06 20:50   ` Alan Cox
2012-06-07 17:07     ` Andi Kleen
2012-06-07 17:13       ` Alan Cox
2012-06-07 17:36       ` Khalid Aziz
2012-06-07 17:08   ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1339091024.25761.896.camel@lyra \
    --to=khalid.aziz@hp.com \
    --cc=bhelgaas@google.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox