Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Cc:     <keith.busch@intel.com>, <helgaas@kernel.org>,
        <mr.nuke.me@gmail.com>, <linux-pci@vger.kernel.org>,
        <Austin.Bolen@dell.com>, <Shyam.Iyer@dell.com>,
        <linux-kernel@vger.kernel.org>, <jonathan.derrick@intel.com>,
        <lukas@wunner.de>, <ruscur@russell.cc>, <sbobroff@linux.ibm.com>,
        <linuxppc-dev@lists.ozlabs.org>
From:   <Alex_Gagniuc@Dellteam.com>
To:     <oohall@gmail.com>, <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is
 disconnected
Thread-Topic: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is
 disconnected
Thread-Index: AQHUT50UQ290XPGvJEGnaSTTjbCF+g==
Date:   Mon, 12 Nov 2018 20:05:41 +0000
Message-ID: <df85813c9860463d85f6c302dfe07b12@ausx13mps321.AMER.DELL.COM>
References: <20180918221501.13112-1-mr.nuke.me@gmail.com>
 <20181107234257.GC41183@google.com> <20181108200855.GE41183@google.com>
 <20181108220117.GA11466@kroah.com>
 <20181108223258.GD2932@localhost.localdomain>
 <20181108224255.GA20619@kroah.com>
 <20d68e586fff4dcca5616d5056f6fc21@ausx13mps321.AMER.DELL.COM>
 <20181108225109.GA3023@kroah.com>
 <16bf9d14bc5f4a90b2b88dd2eb165186@ausx13mps321.AMER.DELL.COM>
 <5da8d8aa9f3818af649b1ac547bc4e6062626ddf.camel@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/11/2018 11:50 PM, Oliver O'Halloran wrote:=0A=
> =0A=
> [EXTERNAL EMAIL]=0A=
> Please report any suspicious attachments, links, or requests for sensitiv=
e information.=0A=
> =0A=
> =0A=
> On Thu, 2018-11-08 at 23:06 +0000, Alex_Gagniuc@Dellteam.com wrote:=0A=
>> On 11/08/2018 04:51 PM, Greg KH wrote:=0A=
>>> On Thu, Nov 08, 2018 at 10:49:08PM +0000, Alex_Gagniuc@Dellteam.com wro=
te:=0A=
>>>> In the case that we're trying to fix, this code executing is a result =
of=0A=
>>>> the device being gone, so we can guarantee race-free operation. I agre=
e=0A=
>>>> that there is a race, in the general case. As far as checking the resu=
lt=0A=
>>>> for all F's, that's not an option when firmware crashes the system as =
a=0A=
>>>> result of the mmio read/write. It's never pretty when firmware gets=0A=
>>>> involved.=0A=
>>>=0A=
>>> If you have firmware that crashes the system when you try to read from =
a=0A=
>>> PCI device that was hot-removed, that is broken firmware and needs to b=
e=0A=
>>> fixed.  The kernel can not work around that as again, you will never wi=
n=0A=
>>> that race.=0A=
>>=0A=
>> But it's not the firmware that crashes. It's linux as a result of a=0A=
>> fatal error message from the firmware. And we can't fix that because FFS=
=0A=
>> handling requires that the system reboots [1].=0A=
> =0A=
> Do we know the exact circumsances that result in firmware requesting a=0A=
> reboot? If it happen on any PCIe error I don't see what we can do to=0A=
> prevent that beyond masking UEs entirely (are we even allowed to do=0A=
> that on FFS systems?).=0A=
=0A=
Pull a drive out at an angle, push two drives in at the same time, pull =0A=
out a drive really slow. If an error is even reported to the OS depends =0A=
on PD state, and proprietary mechanisms and logic in the HW and FW. OS =0A=
is not supposed to mask errors (touch AER bits) on FFS.=0A=
=0A=
Sadly, with FFS, behavior can and does change from BIOS version to BIOS =0A=
version. On one product, for example, we eliminated a lot of crashes by =0A=
simply not reporting some classes of PCIe errors to the OS.=0A=
=0A=
Alex=0A=
=0A=
>> If we're going to say that we don't want to support FFS because it's a=
=0A=
>> separate code path, and different flow, that's fine. I am myself, not a=
=0A=
>> fan of FFS. But if we're going to continue supporting it, I think we'll=
=0A=
>> continue to have to resolve these sort of unintended consequences.=0A=
>>=0A=
>> Alex=0A=
>>=0A=
>> [1] ACPI 6.2, 18.1 - Hardware Errors and Error Sources=0A=
> =0A=
> =0A=
=0A=