On Sun, Oct 11, 2026 at 10:39:26AM +0000, [email protected] 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 <[email protected]>
> 
> 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-66ba92997...@gmail.com?part=1


Reply via email to