On Fri, Mar 07, 2025 at 03:00:09PM +0100, Greg KH wrote:
> On Fri, Mar 07, 2025 at 08:32:55AM -0400, Jason Gunthorpe wrote:
> > On Fri, Mar 07, 2025 at 11:28:37AM +0100, Simona Vetter wrote:
> >
> > > > I wouldn't say it is wrong. It is still the correct thing to do, and
> > > > following down the normal cleanup paths is a good way to ensure the
> > > > special case doesn't have bugs. The primary difference is you want to
> > > > understand the device is dead and stop waiting on it faster. Drivers
> > > > need to consider these things anyhow if they want resiliency against
> > > > device crashes, PCI link wobbles and so on that don't involve
> > > > remove().
> > >
> > > Might need to revisit that discussion, but Greg didn't like when we asked
> > > for a pci helper to check whether the device is physically gone (at least
> > > per the driver model). Hacking that in drivers is doable, but feels
> > > icky.
> >
> > I think Greg is right here, the driver model has less knowledge than
> > the driver if the device is alive.
>
> That's not why I don't want this. Think about this sequence:
> if (!device_is_gone(dev)) {
> // do something
> }
> right after you check it, the value can change.
Oh, I imagined this would latch off. For instance if you hotunplug a
PCI struct device then that struct device will be destroyed
eventually. If in the meantime a PCI device is re-discovered at the
same BDF it would have to wait until the prior one is sufficiently
destroyed before creating a new struct device and getting plugged in.
> Handle the real cases, like you are are saying here, and then all should
> be ok.
Yes, if you handle physical device unplug, PCI device unplug, and PCI
device failure recovery then you cover all the actual production use
cases. That is already so comprehesive and hard that driver writers
will be overjoyed with the result anyhow :)
Jason
