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 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?