On Fri, Aug 15, 2025 at 09:14:28AM +0000, Tian, Kevin wrote: > > 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.. Ah, that's a good point! I missed that one.. > > + /* 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... It would feel odd to me, if that could happen. So, failing it with -EBUSY sounds plausible to me. Thanks! Nicolin
