Re: [Xen-devel] [PATCH v4 02/13] xen/pvcalls: implement frontend disconnect

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 20 Sep 2017, Boris Ostrovsky wrote:
> >  static int pvcalls_front_remove(struct xenbus_device *dev)
> >  {
> > +   struct pvcalls_bedata *bedata;
> > +   struct sock_mapping *map = NULL, *n;
> > +
> > +   bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> > +   dev_set_drvdata(&dev->dev, NULL);
> > +   pvcalls_front_dev = NULL;
> 
> One more comment on this patch: should this be the last thing to do?
> pvcalls_front_dev is what prevents pvcalls_front_probe() from proceeding
> and even though I am not sure a probe can be initiated while we are here
> perhaps moving this to the end would make things slightly safer.

pvcalls_front_dev = NULL is set early to prevent most other functions
(connect, listen, etc) from proceeding.

On the other end, pvcalls_front_probe can continue safely in parallel
with pvcalls_front_remove to add a new frontend-backend connection
(which is not supported today anyway). pvcalls_front_probe would be
called with a different xenbus_device parameter.


> > +   if (bedata->irq >= 0)
> > +           unbind_from_irqhandler(bedata->irq, dev);
> > +
> > +   smp_mb();
> > +   while (atomic_read(&pvcalls_refcount) > 0)
> > +           cpu_relax();
> > +   list_for_each_entry_safe(map, n, &bedata->socket_mappings, list) {
> > +           pvcalls_front_free_map(bedata, map);
> > +           kfree(map);
> > +   }
> > +   list_for_each_entry_safe(map, n, &bedata->socketpass_mappings, list) {
> > +           spin_lock(&bedata->socket_lock);
> > +           list_del_init(&map->list);
> > +           spin_unlock(&bedata->socket_lock);
> > +           kfree(map);
> > +   }
> > +   if (bedata->ref >= 0)
> > +           gnttab_end_foreign_access(bedata->ref, 0, 0);
> > +   kfree(bedata->ring.sring);
> > +   kfree(bedata);
> > +   xenbus_switch_state(dev, XenbusStateClosed);
> >     return 0;
> >  }
> >  
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel