On Thu, Oct 31, 2024 at 09:56:37AM -0700, Nicolin Chen wrote:
On Thu, Oct 31, 2024 at 10:29:41AM -0300, Jason Gunthorpe wrote:
On Wed, Oct 30, 2024 at 02:35:27PM -0700, Nicolin Chen wrote:
+void iommufd_vdevice_destroy(struct iommufd_object *obj) +{
- struct iommufd_vdevice *vdev =
container_of(obj, struct iommufd_vdevice, obj);- struct iommufd_viommu *viommu = vdev->viommu;
- /* xa_cmpxchg is okay to fail if alloc returned -EEXIST previously */
- xa_cmpxchg(&viommu->vdevs, vdev->id, vdev, NULL, GFP_KERNEL);
There are crazy races that would cause this not to work. Another thread could have successfully destroyed whatever caused EEXIST and the successfully registered this same vdev to the same id. Then this will wrongly erase the other threads entry.
It would be better to skip the erase directly if the EEXIST unwind is being taken.
Hmm, is the "another thread" an alloc() or a destroy()?
I was thinking both
It doesn't seem to me that there could be another destroy() on the same object since this current destroy() is the abort to an unfinalized object. And it doesn't seem that another alloc() will get the same vdev ptr since every vdev allocation in the alloc() will be different?
Ah so you are saying that since the vdev 'old' is local to this thread it can't possibly by aliased by another?
I was worried the id could be aliased, but yes, that seems right that the vdev cmpxchg would reject that.
So lets leave it
Jason