[PATCH v2 2/3] iommufd/viommu: Publish a vDEVICE only after vdevice_init() succeeds
Jason Gunthorpe
jgg at nvidia.com
Mon Jul 6 12:47:37 PDT 2026
On Mon, Jul 06, 2026 at 11:05:51AM -0700, Nicolin Chen wrote:
> On Mon, Jul 06, 2026 at 02:23:56PM -0300, Jason Gunthorpe wrote:
> > On Sun, Jul 05, 2026 at 10:36:10PM -0700, Nicolin Chen wrote:
> > > @@ -218,18 +218,28 @@ int iommufd_vdevice_alloc_ioctl(struct iommufd_ucmd *ucmd)
> > > */
> > > idev->vdev = vdev;
> > >
> > > - curr = xa_cmpxchg(&viommu->vdevs, virt_id, NULL, vdev, GFP_KERNEL);
> > > - if (curr) {
> > > - rc = xa_err(curr) ?: -EEXIST;
> > > + /*
> > > + * Reserve the slot with a zero entry (reads back as NULL) until the
> > > + * vdevice_init() op accepts the vDEVICE. Only the xa_* helpers hide a
> > > + * reserved entry, so never use a raw xas_* iterator on this xarray.
> > > + */
> > > + rc = xa_insert(&viommu->vdevs, virt_id, NULL, GFP_KERNEL);
> > > + if (rc) {
> >
> > Why xa_insert() not xa_reserve() ?
>
> xa_reserve's kdoc says:
> "* If there is already something stored at @index, this function does
> * nothing"
>
> By its implementation, it wouldn't return an error on duplication?
Yes, OK that's a good reason
The way I usually write this pattern is two cmpxchgs, the first
NULL -> XA_ZERO_ENTRY and the second XA_ZERO_ENTRY to the final value.
The latter failing would be a WARN_ON condition, but this is fine too
Jason
More information about the linux-arm-kernel
mailing list