From nobody Fri Nov 14 06:42:16 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1585795625; cv=none; d=zohomail.com; s=zohoarc; b=BW4C7rqXxPUsmjblE0XWbsU43LURCtjC2wQzkeTI2E6goPR4FBUQniOabCx7+T9hDvMDoLYRP8vYPoFt3mIE7QvREwZ7r4Gw+x4dZ+Z/WqFpxXpaqglYPvwDRQGdLTsWmeKiSsbcFOzwV1ASHXCvvuuFETk4rnE0W1aFNKQGx8s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1585795625; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=jocdY6yZrH5FtLkLFmx58cZbsx47BDy1p18i2dJ1alg=; b=nRaeIec4Ckkl9PzDgJ+UyBzRoqkr2+jyDS2ROD8unvI1L8j0SaGCDcZ2CsaC8OCrdg5yPEkJqCb55uvo/l68nQkWqYYZtLpwwUskXJkkYX68PVnzxa8OukS0Gmc6qbjoicJjsWgxbK4t7DmvWWVEiAIzNSk2yVIjbgcRjLOFKCo= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1585795625905605.1807210297646; Wed, 1 Apr 2020 19:47:05 -0700 (PDT) Received: from localhost ([::1]:60926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJpsl-0002wv-Vl for importer@patchew.org; Wed, 01 Apr 2020 22:47:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47104) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJprH-00027x-57 for qemu-devel@nongnu.org; Wed, 01 Apr 2020 22:45:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jJprG-0005KP-0F for qemu-devel@nongnu.org; Wed, 01 Apr 2020 22:45:31 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:38422 helo=huawei.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jJprB-0004lE-Tw; Wed, 01 Apr 2020 22:45:26 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 0854D657555145C53158; Thu, 2 Apr 2020 10:45:20 +0800 (CST) Received: from localhost (10.133.205.53) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.487.0; Thu, 2 Apr 2020 10:45:00 +0800 From: Ying Fang To: , Subject: [PATCH v2] util/async: Add memory barrier to aio_ctx_prepare Date: Thu, 2 Apr 2020 10:44:31 +0800 Message-ID: <20200402024431.1629-1-fangying1@huawei.com> X-Mailer: git-send-email 2.22.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.133.205.53] X-CFilter-Loop: Reflected Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 45.249.212.35 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fam@euphon.net, zhang.zhanghailiang@huawei.com, qemu-stable@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, wu.wubin@huawei.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" Qemu main thread is found to hang up in the mainloop when doing image format convert on aarch64 platform and it is highly reproduceable by executing test using: qemu-img convert -f qcow2 -O qcow2 origin.qcow2 converted.qcow2 This mysterious hang can be explained by a race condition between the main thread and an io worker thread. There can be a chance that the last worker thread has called aio_bh_schedule_oneshot and it is checking against notify_me to deliver a notfiy event. At the same time, the main thread is calling aio_ctx_prepare however it first calls qemu_timeout_ns_to_ms, thus the worker thread did not see notify_me as true and did not send a notify event. The time line can be shown in the following way: Main Thread ------------------------------------------------ aio_ctx_prepare atomic_or(&ctx->notify_me, 1); /* out of order execution goes here */ *timeout =3D qemu_timeout_ns_to_ms(aio_compute_timeout(ctx)); Worker Thread ----------------------------------------------- aio_bh_schedule_oneshot -> aio_bh_enqueue aio_notify smp_mb(); if (ctx->notify_me) { /* worker thread checks notify_me here */ event_notifier_set(&ctx->notifier); atomic_mb_set(&ctx->notified, true); } Normal VM runtime is not affected by this hang since there is always some timer timeout or subsequent io worker come and notify the main thead. To fix this problem, a memory barrier is added to aio_ctx_prepare and it is proved to have the hang fixed in our test. This hang is not observed on the x86 platform however it can be easily reproduced on the aarch64 platform, thus it is architecture related. Not sure if this is revelant to Commit eabc977973103527bbb8fed69c91cfaa6691= f8ab Signed-off-by: Ying Fang Signed-off-by: zhanghailiang Reported-by: Euler Robot --- v2: add comments before the barrier --- util/async.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/util/async.c b/util/async.c index b94518b..89a4f3e 100644 --- a/util/async.c +++ b/util/async.c @@ -250,7 +250,8 @@ aio_ctx_prepare(GSource *source, gint *timeout) AioContext *ctx =3D (AioContext *) source; =20 atomic_or(&ctx->notify_me, 1); - + /* Make sure notify_me is set before aio_compute_timeout */ + smp_mb(); /* We assume there is no timeout already supplied */ *timeout =3D qemu_timeout_ns_to_ms(aio_compute_timeout(ctx)); =20 --=20 1.8.3.1