Re: [PATCH RFC 2/3] PCI: pciehp: Report surprise removal from pciehp_isr()

From: Abhin Parekadan Jose

Date: Sun Sep 20 2026 - 13:27:44 EST


On Sat, Sep 12, 2026 at 11:57:38AM -0400, Michael S. Tsirkin wrote:
> On Sat, Sep 05, 2026 at 06:38:59PM +0000, Abhin Parekadan Jose wrote:
> >
> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > index 23b1605e783a..4e17878edeab 100644
> > --- a/drivers/pci/pci.h
> > +++ b/drivers/pci/pci.h
> > @@ -805,6 +805,12 @@ static inline int pci_dev_set_disconnected(struct pci_dev *dev, void *unused)
> > pci_dev_set_io_state(dev, pci_channel_io_perm_failure);
> > pci_doe_disconnected(dev);
> >
> > + return 0;
> > +}
> > +
> > +static inline int schedule_notification_work(struct pci_dev *dev, void *unused)
> > +{
> > + pci_dev_set_disconnected(dev, NULL);
>
>
> Does this not break what patch 1 was trying to do,
> for everyone who does not call schedule_notification_work,
> that is, everyone except pciehp?
>
> I'd say do the reverse: make schedule_notification_work
> schedule the work, and have both pcieh and
> pci_dev_set_disconnected call that.
>

Thanks for the review.

Yes - I've already done that locally. It'll be in the next version.

I've also been working through the races Sashiko flagged and looking for
other race conditions.

One is left: pciehp_is_spurious_link_change() ends up consuming the
one-shot flags PCI_DPC_RECOVERED and PCI_LINK_CHANGED, so whichever of
pciehp_ist() and pciehp_disconnect_work() calls it first consumes the
flag. I have a crude fix but it's untested; I'll get to it next weekend.

>
> > if (READ_ONCE(dev->disconnect_work_enable)) {
> > /* Make sure work is up to date. */
> > smp_rmb();
> > --
> > 2.51.1
> >
>