> From: Nicolin Chen <nicolinc@xxxxxxxxxx> > Sent: Tuesday, August 12, 2025 6:59 AM > [...] > However, if there is a domain attachment/replacement happening during an > ongoing reset, ATS routines may be re-activated between the two function > calls. So, introduce a new pending_reset flag in group_device to defer an > attachment during a reset, allowing iommu core to cache target domains in > the SW level while bypassing the driver. The iommu_dev_reset_done() will > re-attach these soft-attached domains, once the device reset is finished. attach could fail e.g. when device and domain are incompatible. This deferred attach (until reset done) makes compatibility check impossible in the resetting window, given the driver attach_dev callback is not called in the normal attach path. Worse.. > + /* Shift RID domain back to group->domain */ > + if (group->domain != group->blocking_domain) > + WARN_ON(__iommu_attach_device(group->domain, dev)); ..means that an user could trigger WARN_ON() easily if he knows an attach would fail. IMHO we may just fail attach request in the resetting window then WARN_ON above makes sense as it's shifting back to a domain which was originally attached to the resetting device. Not sure any valid case where one would want to attach/replace domain for a resetting device...
