linux-kernel - Re: [PATCH] pci: add pci_dev_is

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: <CAATamawK53+XvZ+FV_1-Td9iFZwHeLX1O+PzCh01twzNAyRZHw@mail.gmail.com>
Date:   Thu, 27 May 2021 11:43:24 +0800
From:   Lambert Wang <lambert.q.wang@...il.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Krzysztof Wilczyński <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pci: add pci_dev_is_alive API

On Thu, May 27, 2021 at 12:23 AM Bjorn Helgaas <helgaas@...nel.org> wrote:
>
> On Wed, May 26, 2021 at 02:12:38PM +0800, Lambert Wang wrote:
> > ...
> > The user is our new PCI driver under development for WWAN devices .
> > Surprise removal could happen under multiple circumstances.
> > e.g. Exception, Link Failure, etc.
> >
> > We wanted this API to detect surprise removal or check device recovery
> > when AER and Hotplug are disabled.
> >
> > I thought the API could be commonly used for many similar devices.
>
> Be careful with this.  pci_device_is_present() is not a good way to
> detect surprise removal.  Surprise removal can happen at any time, for
> example, it can occur after you call pci_device_is_present() but
> before you use the result:
>
>   present = pci_device_is_present(pdev);
>   /* present == true */
>   /* device may be removed here */
>   if (present)
>     xxx; /* this operation may fail */
>
> You have to assume that *any* operation on the device can fail because
> the device has been removed.  In general, there's no response for a
> PCIe write to the device, so you can't really check whether a write
> has failed.
>
> There *are* responses for reads, of course, if the device has been
> removed, a read will cause a failure response.  Most PCIe controllers
> turn that response into ~0 data to satisfy the read.  So the only
> reliable way to detect surprise removal is to check for ~0 data when
> doing an MMIO read from the device.  Of course, ~0 may be either valid
> data or a symptom of a failure response, so you may have to do
> additional work to distinguish those two cases.

Thanks for reminding.  :)

Yes the check has race conditions. When the driver is doing recovery detection,
the check result is not reliable.

It is pretty useful when the driver wants to confirm if the device is
absent *after*
the driver finds it's not working as expected.

>
> Bjorn