From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Message-ID: <58192cf94de3941f9141aa3203399ae2bcdf6b7a.camel@kernel.crashing.org> Subject: Re: PCIe enable device races (Was: [PATCH v3] PCI: Data corruption happening due to race condition) From: Benjamin Herrenschmidt To: Bjorn Helgaas , Hari Vyas Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, ray.jui@broadcom.com Date: Wed, 15 Aug 2018 14:44:22 +1000 In-Reply-To: <5e42f7990673d11e3a020e7efcfd333215d48138.camel@kernel.crashing.org> References: <1530608741-30664-1-git-send-email-hari.vyas@broadcom.com> <20180731163727.GK45322@bhelgaas-glaptop.roam.corp.google.com> <5e42f7990673d11e3a020e7efcfd333215d48138.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-ID: On Wed, 2018-08-15 at 14:16 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-08-15 at 13:35 +1000, Benjamin Herrenschmidt wrote: > > What's really needed is a per device mutex covering all those operations > > on a given device. (This would also allow to get rid of those games with > > atomics). > > > > Any comments ? > > Note: I'm experienting with a per-pci_dev mutex to protect the device > state. If it works out, I suggest we add it, then progressively > move things one by one under the protection of the mutex. > > Any objection to the approach ? If it fixes my problem, I'll send > preliminary patches that cover the basic enable/disable and bus > master settings to start with. We should try to get them into > stable as this is breaking real world stuff for us. > > I suspect large x86 systems get lucky because their BIOSes do all > the enables. It would be possible to reproduce the races there by > hot-pluging a large external drawer using a cable card with a switch BTW. Should we plan a PCIe microconf for Plumbers ? Cheers, Ben.