From mboxrd@z Thu Jan  1 00:00:00 1970
From: Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: barriers before {req/rsp}_cons = cons?
Date: Fri, 18 Jul 2008 19:52:40 +0100
Message-ID: <20080718185240.GH4576@implementation>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

Hello,

In a bunch of places, one can read code like

cons = 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 = ++cons;

Shouldn't there be a full barrier just before the req_cons assignation?
I guess we are currently not seeing bugs at least because the req will
not be overwriten until we loop in the ring, but it seems to me there
may be a bug here.

Samuel