On Tue, 2025-09-09 at 15:52 +0200, Benjamin Block wrote:
> On Thu, Sep 04, 2025 at 10:59:49AM +0200, Niklas Schnelle wrote:
> > When a PCI device is removed with surprise hotplug, there may still be
> > attempts to attach the device to the default domain as part of tear down
> > via (__iommu_release_dma_ownership()), or because the removal happens
> > during probe (__iommu_probe_device()). In both cases zpci_register_ioat()
> > fails with a cc value indicating that the device handle is invalid. This
> > is because the device is no longer part of the instance as far as the
> > hypervisor is concerned.
> >
> > Currently this leads to an error return and s390_iommu_attach_device()
> > fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()
> > because attaching to the default domain must never fail.
> >
> > With the device fenced by the hypervisor no DMAs to or from memory are
> > possible and the IOMMU translations have no effect. Proceed as if the
> > registration was successful and let the hotplug event handling clean up
> > the device.
> >
> > This is similar to how devices in the error state are handled since
> > commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device
> > is in error state") except that for removal the domain will not be
> > registered later. This approach was also previously discussed at the
> > link.
> >
> > Handle both cases, error state and removal, in a helper which checks if
> > the error needs to be propagated or ignored. Avoid magic number
> > condition codes by using the pre-existing, but never used, defines for
> > PCI load/store condition codes and rename them to reflect that they
> > apply to all PCI instructions.
> >
> > Cc: stable@xxxxxxxxxxxxxxx # v6.2
>
> Oh, I just noticed that Niklas. You added `Cc: stable@xxxxxxxxxxxxxxx`, but
> didn't actually include the address on the actual Cc of the mail? Was that
> intentional?
>
Yes it was intentional. It's my understanding that the tag is enough
for the stable team to pick the commit up once it lands in Linus' tree.
And I do have stable@xxxxxxxxxxxxxxx explicitly ignored in b4 to
prevent accidentally sending not-yet-ready or internal patches there.
There is an alternative approach of getting patches in stable by
sending them to the stable mailinglist but accodring to
Documentation/process/stable-kernel-rules.rst the tag is preferred.
Sadly the docs don't spell out that Ccing the list isn't needed though
I feel like it is implied by the "Cc: stable@xxxxxxxxxx" variant where
the docs mention that mails send by git send-email will go nowhere.
Thanks,
Niklas
