Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751751AbdITUdY (ORCPT ); Wed, 20 Sep 2017 16:33:24 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:48835 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390AbdITUdX (ORCPT ); Wed, 20 Sep 2017 16:33:23 -0400 Subject: Re: [PATCH v4 02/13] xen/pvcalls: implement frontend disconnect To: Stefano Stabellini , xen-devel@lists.xen.org References: <1505516440-11111-1-git-send-email-sstabellini@kernel.org> <1505516440-11111-2-git-send-email-sstabellini@kernel.org> Cc: linux-kernel@vger.kernel.org, jgross@suse.com, Stefano Stabellini From: Boris Ostrovsky Message-ID: <7f24ec66-d370-5f2f-3c6a-8e949c8ed074@oracle.com> Date: Wed, 20 Sep 2017 16:32:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1505516440-11111-2-git-send-email-sstabellini@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 918 Lines: 36 > + > +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? > + > +/* 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. -boris