mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Khalid Aziz <khalid.aziz@hp.com>
To: Matthew Garrett <mjg@redhat.com>
Cc: linux-kernel@vger.kernel.org, bhelgaas@google.com,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH] Disable Bus Master on PCI device shutdown
Date: Wed, 06 Jun 2012 10:17:43 -0600	[thread overview]
Message-ID: <1338999463.25761.630.camel@lyra> (raw)
In-Reply-To: <20120606135009.GB1517@srcf.ucam.org>

On Wed, 2012-06-06 at 14:50 +0100, Matthew Garrett wrote:
> On Fri, Apr 27, 2012 at 01:00:33PM -0600, Khalid Aziz wrote:
> > Disable Bus Master bit on the device in
> > pci_device_shutdown() to ensure PCI devices do not continue
> > to DMA data after shutdown. This can cause memory
> > corruption in case of a kexec where the current kernel
> > shuts down and transfers control to a new kernel while a
> > PCI device continues to DMA to memory that does not belong
> > to it any more in the new kernel.
> 
> This protects against the case where a piece of hardware is continuing 
> to DMA even after the driver shutdown method has been called? I'm not 
> convinced this is safe. Some Broadcom parts will crash if busmastering 
> is disabled while they're still performing DMA, and they'll then hang 
> the bus if reenabled. There's also the risk that the hardware will start 
> DMAing again if it's reenabled after being shut down. It seems like 
> you're covering over the case where the driver didn't correctly quiesce 
> the hardware, but you risk triggering other bugs instead.

Hi Matthew,

That is a good piece of information. I see your concern and agree with
it. My take is shutdown method for the drivers will end all active I/O
and clear the I/O queue. This should take care of any DMA caused by an
I/O request originating in the kernel. For devices like NIC, a DMA can
be triggered by an incoming packet and I am trying to stop that by
disabling Bus Master bit. This is the issue that was reported on kexec
mailing list in July of last year and it involved qla driver. I observed
similar problem with kexec on ia64 many years ago and had written a
patch to disable Bus Master bit on kexec. This patch was in ia64 tree
for some time before it was removed. HP shipped kernels with this patch
for many years and those kernels have been in deployment in field for
some 7+ years with no problems.

So it seems we do have a real problem. I understand there are devices
with quirks related to Bus Master bit and it really helps to know about
those. I have found disabling Bus Master bit has worked very well for
all of the systems I have deployed kernels with this patch on but I have
not come even close to having tried all PCI devices out there. I am open
to other suggestions on how to solve this problem and make kexec
reliable.

Thanks Matthew! I appreciate the feedback.

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



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

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-27 19:00 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 [this message]
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
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=1338999463.25761.630.camel@lyra \
    --to=khalid.aziz@hp.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mjg@redhat.com \
    /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

Powered by JetHome