From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: barriers before {req/rsp}_cons = cons? Date: Fri, 18 Jul 2008 20:34:45 +0100 Message-ID: <20080718193445.GJ4576@implementation> References: <20080718185240.GH4576@implementation> <20080718193304.GI4576@implementation> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <20080718193304.GI4576@implementation> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Samuel Thibault, le Fri 18 Jul 2008 20:33:04 +0100, a =E9crit : > Keir Fraser, le Fri 18 Jul 2008 20:31:13 +0100, a =E9crit : > > > cons =3D netif->tx.req_cons; > > > rmb(); /* Ensure that we see the request before we copy it. */ > > > memcpy(&txreq, RING_GET_REQUEST(&netif->tx, i), sizeof(txreq)); > > > some checks > > > netif->tx.req_cons =3D ++cons; > >=20 > > Could you describe the race you believe is made possible by the absen= ce of > > the barrier? >=20 > It is very unlikely, but the write into req_cons could happen before > actually doing the memcpy, (more precisely, the read, of course). > and so another processor could try to reuse > the same request slot. Samuel