Re: [PATCH v2] vhost-vdpa: initialize state before publishing cdev

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Oct 11, 2026 at 10:39:26AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] vhost_vdpa: spurious -EBUSY on open() due to uevent race during probe
> --


Linfeng do you want to address the bot review on list pls?

> commit cef3a58744e8aa0a22f86fbbe577797fa0a78e31
> Author: Linfeng Sun <linfeng.sun.dev@gmail.com>
> 
> vhost-vdpa: initialize state before publishing cdev
> 
> Initialize the completion and as hash buckets before cdev_device_add()
> makes the device accessible.
> 
> > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> > index ff7d907191712..6cff1ed2004ee 100644
> > --- a/drivers/vhost/vdpa.c
> > +++ b/drivers/vhost/vdpa.c
> > @@ -1655,7 +1655,7 @@ static int vhost_vdpa_probe(struct vdpa_device *vdpa)
> >  		return minor;
> >  	}
> >  
> > -	atomic_set(&v->opened, 0);
> > +	atomic_set(&v->opened, 1);
> >  	spin_lock_init(&v->config_lock);
> >  	v->minor = minor;
> >  	v->vdpa = vdpa;
> > @@ -1678,16 +1678,17 @@ static int vhost_vdpa_probe(struct vdpa_device *vdpa)
> >  
> >  	cdev_init(&v->cdev, &vhost_vdpa_fops);
> >  	v->cdev.owner = THIS_MODULE;
> > +	init_completion(&v->completion);
> > +	for (i = 0; i < VHOST_VDPA_IOTLB_BUCKETS; i++)
> > +		INIT_HLIST_HEAD(&v->as[i]);
> >  
> >  	r = cdev_device_add(&v->cdev, &v->dev);
> >  	if (r)
> >  		goto err;
> >  
> > -	init_completion(&v->completion);
> >  	vdpa_set_drvdata(vdpa, v);
> >  
> > -	for (i = 0; i < VHOST_VDPA_IOTLB_BUCKETS; i++)
> > -		INIT_HLIST_HEAD(&v->as[i]);
> > +	atomic_set_release(&v->opened, 0);
> 
> [Severity: Medium]
> Will this cause a spurious -EBUSY for userspace orchestration tools like udev?
> 
> When cdev_device_add() registers the character device, it fires a KOBJ_ADD
> uevent. If userspace reacts immediately by calling open(), it will hit
> vhost_vdpa_open():
> 
> drivers/vhost/vdpa.c:vhost_vdpa_open() {
> 	...
> 	opened = atomic_cmpxchg(&v->opened, 0, 1);
> 	if (opened)
> 		return -EBUSY;
> 	...
> }
> 
> Since v->opened was artificially set to 1 earlier in probe, open() will be
> rejected with -EBUSY until atomic_set_release() clears it, which might
> break normal userspace orchestration that attempts to open the device right
> after the uevent.
> 
> >  
> >  	return 0;
> >
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261011-fix-null-pointer-in-vhost_vdpa_release-v2-1-66ba929971ce@gmail.com?part=1