From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: new netfront and occasional receive path lockup Date: Fri, 10 Sep 2010 12:42:32 +1000 Message-ID: <4C899B18.3040104@goop.org> References: <1282495384.12843.11.camel@leto.intern.saout.de> <4C73166D.3030000@goop.org> <20100909185058.GR2804@reaktio.net> <4C8981E5.6010000@goop.org> <4C8996FE.2040500@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Xu, Dongxiao" Cc: "xen-devel@lists.xensource.com" , Christophe Saout List-Id: xen-devel@lists.xenproject.org On 09/10/2010 12:37 PM, Xu, Dongxiao wrote: >> However, I am concerned about these manipulations of a cross-cpu >> shared variable without any barriers or other ordering constraints. >> Are you sure this code is correct under any reordering (either by the >> compiler or CPUs); and if the compiler decides to access it more or >> less often than the source says it should? > Do you mean the flag "np->rx.sring->private.netif.smartpoll_active"? > It is a flag in shared ring structure, Therefore operations towards > this flag are the same as other component in shared ring, such as > under spinlock, etc. Spinlocks are no use for inter-domain synchronization, only within a domain. The other ring operations are carefully ordered with appropriate memory barriers in specific places; that's why I'm a bit concerned about their absence for the smartpoll_active flag. Even if they are not necessary, I'd like to see an analysis as to why. J