[RFC PATCH] nvme: avoid race-conditions when enabling devices

[srinath.mannam@broadcom.com (Srinath Mannam)]

Hi Marta,

I could not get time to work on this.
The present patch works for our platforms. so we continue with that.
I will update new changes little later.
If you have time, please try the same patch and let us know if any issue you
see.

Regards,
Srinath.

-----Original Message-----
From: Marta Rybczynska [mailto:mrybczyn@kalray.eu]
Sent: Friday, March 23, 2018 12:58 PM
To: Bjorn Helgaas <helgaas at kernel.org>
Cc: Keith Busch <keith.busch at intel.com>; Ming Lei <ming.lei at redhat.com>;
axboe at fb.com; hch at lst.de; sagi at grimberg.me; linux-nvme at lists.infradead.org;
linux-kernel at vger.kernel.org; bhelgaas at google.com;
linux-pci at vger.kernel.org; Pierre-Yves Kerbrat <pkerbrat at kalray.eu>; Srinath
Mannam <srinath.mannam at broadcom.com>
Subject: Re: [RFC PATCH] nvme: avoid race-conditions when enabling devices


> On Wed, Mar 21, 2018@05:10:56PM +0100, Marta Rybczynska wrote:
>>
>> The problem may happen also with other device doing its probe and
>> nvme running its workqueue (and we probably have seen it in practice
>> too). We were thinking about a lock in the pci generic code too,
>> that's why I've put the linux-pci@ list in copy.
>
> Yes, this is a generic problem in the PCI core.  We've tried to fix it
> in the past but haven't figured it out yet.
>
> See 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges")
> and 0f50a49e3008 ("Revert "PCI: Avoid race while enabling upstream
> bridges"").
>
> It's not trivial, but if you figure out a good way to fix this, I'd be
> thrilled.
>

Bjorn, Srinath, are you aware of anyone working on an updated fix for this
one?

Marta