linux-kernel - Re: [PATCH V2] PCI/portdrv: do not disable device on reboot/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, 24 May 2018 08:07:27 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Sinan Kaya <okaya@...eaurora.org>
Cc:     linux-pci@...r.kernel.org, timur@...eaurora.org, ryan@...nie.org,
        linux-arm-msm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, stable@...r.kernel.org,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Frederick Lawler <fred@...dlawl.com>,
        Dongdong Liu <liudongdong3@...wei.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        open list <linux-kernel@...r.kernel.org>,
        Don Brace <don.brace@...rosemi.com>,
        esc.storagedev@...rosemi.com, linux-scsi@...r.kernel.org
Subject: Re: [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown

On Thu, May 24, 2018 at 07:43:05AM -0400, Sinan Kaya wrote:
> On 5/23/2018 6:57 PM, Sinan Kaya wrote:
> >> The crash seems to indicate that the hpsa device attempted a DMA after
> >> we cleared the Root Port's PCI_COMMAND_MASTER, which means
> >> hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
> >> shutdown methods don't disable device DMA, so it's in good company).
> > All drivers are expected to shutdown DMA and interrupts in their shutdown()
> > routines. They can skip removing threads, data structures etc. but DMA and
> > interrupt disabling are required. This is the difference between shutdown()
> > and remove() callbacks.
> 
> I found this note yesterday to see why we are not disabling the
> devices in the PCI core itself. 
> 
> pci_device_remove()
> 
> 	/*
> 	 * We would love to complain here if pci_dev->is_enabled is set, that
> 	 * the driver should have called pci_disable_device(), but the
> 	 * unfortunate fact is there are too many odd BIOS and bridge setups
> 	 * that don't like drivers doing that all of the time.
> 	 * Oh well, we can dream of sane hardware when we sleep, no matter how
> 	 * horrible the crap we have to deal with is when we are awake...
> 	 */ 
> 
> Ryan, can you discard the previous patch and test this one instead?
> remove() path in hpsa driver seems to call pci_disable_device() via 
> 
> hpsa_remove_one()
> 	hpsa_free_pci_init()
> 
> but nothing on the shutdown path.
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 4ed3d26..3823f04 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -8651,6 +8651,7 @@ static void hpsa_shutdown(struct pci_dev *pdev)
>         h->access.set_intr_mask(h, HPSA_INTR_OFF);
>         hpsa_free_irqs(h);                      /* init_one 4 */
>         hpsa_disable_interrupt_mode(h);         /* pci_init 2 */
> +       pci_disable_device(h->pdev);
>  }

I suspect this will make things "work" (if the device can't attempt
DMA, no Unsupported Request error will occur).

But I'm concerned that the reason for the DMA might that hpsa is
transferring buffers from system memory to the hpsa device, and if we
arbitrarily terminate those transfers with pci_disable_device(), we
may leave the hpsa device in an inconsistent state, e.g., with a dirty
filesystem.

But we really need guidance from an hpsa expert.  I don't know the
filesystem/SCSI/hpsa details.

Bjorn