On Dec 13, 2023 / 16:05, Andy Shevchenko wrote:
> On Tue, Dec 12, 2023 at 08:47:46PM +0900, Shin'ichiro Kawasaki wrote:
> > p2sb_bar() unhides P2SB device to get resources from the device. It
> > guards the operation by locking pci_rescan_remove_lock so that parallel
> > rescans do not find the P2SB device. However, this lock causes deadlock
> > when PCI bus rescan is triggered by /sys/bus/pci/rescan. The rescan
> > locks pci_rescan_remove_lock and probes PCI devices. When PCI devices
> > call p2sb_bar() during probe, it locks pci_rescan_remove_lock again.
> > Hence the deadlock.
> >
> > To avoid the deadlock, do not lock pci_rescan_remove_lock in p2sb_bar().
> > Instead, do the lock at fs_initcall. Introduce p2sb_cache_resources()
> > for fs_initcall which gets and caches the P2SB resources. At p2sb_bar(),
> > refer the cache and return to the caller.
>
> ...
>
> > +/* Cache BAR0 of P2SB device from function 0 ot 7 */
> > +#define NR_P2SB_RES_CACHE 8
>
> Here... (at least some better comment with TODO needs to be added,
> and next patches can address that).
>
> > struct resource *bar0 = &pdev->resource[0];
>
> ...and here... (okay, not exactly here, but with the same idea,
> to use pci_resource_n() macro)
>
> > + if (!PCI_FUNC(devfn_p2sb)) {
> > + slot_p2sb = PCI_SLOT(devfn_p2sb);
> > + for (fn = 1; fn < 8; fn++)
>
> ...and here...
>
> > + p2sb_scan_and_cache(bus, PCI_DEVFN(slot_p2sb, fn));
> > + }
>
> ...and so on I gave comments. Any reason why they left unaddressed?
Andy, thanks for the response, but I'm not sure about the comments you gave.
I guess you responded to the RFC v1 patch but it somehow did not reach to me,
probably. According to the lore archive, only Hans responded to the RFC v1 [1].
If this guess is correct, could you resend your comments on the RFC v1?
[1] https://lore.kernel.org/platform-driver-x86/20231201104759.949340-1-shinichiro.kawasaki@xxxxxxx/
