Re: [PATCH v2] s390x/pci: prevent null pointer dereference during zpci hot unplug

[Halil Pasic <pasic@linux.ibm.com>]

On Thu, 12 Feb 2026 11:55:15 -0500
Matthew Rosato <mjrosato@linux.ibm.com> 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