On Thu, 12 Feb 2026 11:55:15 -0500 Matthew Rosato <[email protected]> wrote:
> > > > Maybe add a word or two why the other dereferences of pbdev->iommu > > not guarded by a null check are safe. > > > > I think we have: > > * s390_pci_sclp_deconfigure > > * s390_pci_msix_init > > * s390_pcihost_reset > > * s390_pci_device_reset > > * mpcifc_service_call > > * stpcifc_service_call > > * s390_pci_read_base > > > > and more. My guess is that the device never gets into a state where > > these operations are permissible, and the code makes sure > > those functions won't be called on a device that has > > pbdev->iommu == NULL. But that is just my guess. > > > > DISCLAIMER: I didn't look at this properly, just asking based > > on a quick look. Some of these may contain explicit or implicit > > checking... > > I mentioned in response to v1 as part of my review that I did look through > all references of pbdev->iommu, as I was also concerned about whether we > needed additional NULL checks. But so far I'm not seeing it - it is largely > implicit, but we don't drive the routines until the device is plugged, not in > reserved|standby and iommu is associated. > > This particular case is because we reach unplug (which also has to happen > after plug of course) but the swizzle is we are reaching unplug exactly > because we are giving up without actually having -successfully- plugged both > the zpci and pci device. > > But anyway, yes, I do think it would be good to add a small blurb to the > commit message. Thanks! I have also assumed that I'm not the first one having this thought. Regards, Halil
