From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCR91-0001yp-6q for qemu-devel@nongnu.org; Wed, 08 Nov 2017 09:15:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCR8w-0001vn-Q1 for qemu-devel@nongnu.org; Wed, 08 Nov 2017 09:15:55 -0500 References: <20171108063447.2842-1-slp@redhat.com> From: Paolo Bonzini Message-ID: <5d4d9db6-f740-c114-9f21-d575eb2d897f@redhat.com> Date: Wed, 8 Nov 2017 15:15:27 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3] util/async: use atomic_mb_set in qemu_bh_cancel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergio Lopez , Pavel Butsykin Cc: qemu-devel@nongnu.org, Fam Zheng , stefanha@redhat.com, qemu-block@nongnu.org On 08/11/2017 15:10, Sergio Lopez wrote: >> I'm not quite sure that the pre-fetched is involved in this issue, >> because pre-fetch reading a certain addresses should be invalidated by >> write on another core to the same addresses. In our case write >> req->state = THREAD_DONE should invalidate read req->state == THREAD_DONE. >> I am inclined to think that there is a memory-reordering read with >> write. It's a very real case for x86 and I don't see the reasons which >> can prevent it: >> > Yes, you're right. This is actually a memory reordering issue. I'm > going to rewrite that paragraph. Well, memory reordering _is_ caused by speculative prefetching, delayed cache invalidation (store buffers), and so on. But it's probably better indeed to replace "pre-fetched" with "outdated". Whoever commits the patch can do the substitution (I can too). Paolo