Re: [PATCH v2 2/3] iommufd/viommu: Publish a vDEVICE only after vdevice_init() succeeds

[Jason Gunthorpe <jgg@nvidia.com>]

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