On Wed, 20 Sep 2017, Boris Ostrovsky wrote: > > + > > +struct pvcalls_bedata { > > + struct xen_pvcalls_front_ring ring; > > + grant_ref_t ref; > > + int irq; > > + > > + struct list_head socket_mappings; > > + struct list_head socketpass_mappings; > > + spinlock_t socket_lock; > > + > > + wait_queue_head_t inflight_req; > > + struct xen_pvcalls_response rsp[PVCALLS_NR_REQ_PER_RING]; > > +}; > > +static struct xenbus_device *pvcalls_front_dev; > > +static atomic_t pvcalls_refcount; > > Should the refcount be per back/frontend?
Yes it is, but only one back/frontend connection is supported by the frontend. I can add a comment. > > + > > +/* first increment refcount, then proceed */ > > +#define pvcalls_enter { \ > > + atomic_inc(&pvcalls_refcount); \ > > + smp_mb(); \ > > +} > > + > > +/* first complete other operations, then decrement refcount */ > > +#define pvcalls_exit { \ > > + smp_mb(); \ > > + atomic_dec(&pvcalls_refcount); \ > > +} > > I think atomic increment/decrement imply a barrier. You are right. From Documentation/core-api/atomic_ops.rst: One very important aspect of these two routines is that they DO NOT require any explicit memory barriers.