Re: [PATCH] PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device()

[Bjorn Helgaas <helgaas@kernel.org>]

On Fri, May 01, 2026 at 02:37:21PM -0500, Bjorn Helgaas wrote:
> On Fri, May 01, 2026 at 10:22:56AM +0900, Krzysztof Wilczyński wrote:
> > Hello,
> > 
> > > Thus, wrap the for_each_pci_dev() loop with pci_lock_rescan_remove() to
> > > serialise against concurrent PCI bus operations.  Add an early return in
> > > pci_proc_attach_device() when dev->procent is already set, making the
> > > function idempotent and symmetric with pci_proc_detach_device() which
> > > clears this field.
> > 
> > A note on testing:
> > 
> >   0-day bot (recent test runs; newer builds will arrive later):
> >     - https://lore.kernel.org/linux-pci/202603162306.2oKy0qcP-lkp@intel.com
> > 
> >   Sashiko's feedback:
> >     - https://sashiko.dev/#/patchset/20260430003542.455198-1-kwilczynski%40kernel.org
> > 
> > Lorenzo Pieralisi did some testing reported outside the mailing list (we
> > talked on IRC) on the platform he had some boot issues.  With this patch
> > applied, the problems seen before were resolved.
> 
> Thanks!  Can we include a link to the problem report and maybe a
> couple lines of the symptoms?
> 
> Also the analysis of Sashiko feedback?
> 
> Sashiko worried about pci_lock_rescan_remove() deadlock between
> pci_proc_init() and PCI controller drivers with async probing.
> pci_proc_init() is a device initcall.  Some drivers are also device
> initcalls (imx_pcie_init(), ks_pcie_init(), rcar_pcie_init()), and it
> looks like they can use async probing.
> 
> Does this rely on the pci_proc_init() device_initcall happening before
> any of the driver device_initcalls?  That would be non-obvious and
> fragile.
> 
> The second sashiko issue (concurrent calls of
> pci_proc_attach_device()) also seems worth a look.  The
> pci_enable_sriov() path isn't serialized by pci_lock_rescan_remove():
> 
>   pci_enable_sriov
>     sriov_enable
>       sriov_add_vfs
>         pci_iov_add_virtfn
>           pci_bus_add_device
>             pci_proc_attach_device
>               bus->procdir = proc_mkdir()
> 
> If two threads race for devices on the same bus, it looks like the
> loser can set bus->procdir back to NULL when proc_mkdir() fails with
> "duplicate entry".
> 
> This is a per-device path, but we're creating a per-bus directory.  I
> wonder if that proc_mkdir() could/should be done in a bus creation
> path?

Where are we at with this patch?  I haven't had a chance to look any
deeper at these questions.