From nobody Sun Apr 28 22:25:06 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.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 (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1549944242930630.8585822948759; Mon, 11 Feb 2019 20:04:02 -0800 (PST) Received: from localhost ([127.0.0.1]:60822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPIX-0006Bj-TX for importer@patchew.org; Mon, 11 Feb 2019 23:03:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPGt-0005Vt-Rg for qemu-devel@nongnu.org; Mon, 11 Feb 2019 23:02:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtPGr-0002o4-7d for qemu-devel@nongnu.org; Mon, 11 Feb 2019 23:02:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46500) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gtPGj-0002bC-TJ; Mon, 11 Feb 2019 23:02:03 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B700389AC9; Tue, 12 Feb 2019 04:02:00 +0000 (UTC) Received: from localhost (unknown [10.64.242.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id A97015C236; Tue, 12 Feb 2019 04:01:47 +0000 (UTC) From: Stefan Hajnoczi To: qemu-devel@nongnu.org Date: Tue, 12 Feb 2019 12:01:34 +0800 Message-Id: <20190212040136.30371-2-stefanha@redhat.com> In-Reply-To: <20190212040136.30371-1-stefanha@redhat.com> References: <20190212040136.30371-1-stefanha@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 12 Feb 2019 04:02:00 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/3] iothread: fix iothread hang when stop too soon X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Laurent Vivier , Thomas Huth , qemu-block@nongnu.org, Peter Maydell , Markus Armbruster , "Michael S. Tsirkin" , "Dr . David Alan Gilbert" , Peter Xu , Max Reitz , Stefan Hajnoczi , Paolo Bonzini , =?UTF-8?q?Luk=C3=A1=C5=A1=20Doktor?= , Eduardo Habkost Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Peter Xu Lukas reported an hard to reproduce QMP iothread hang on s390 that QEMU might hang at pthread_join() of the QMP monitor iothread before quitting: Thread 1 #0 0x000003ffad10932c in pthread_join #1 0x0000000109e95750 in qemu_thread_join at /home/thuth/devel/qemu/util/qemu-thread-posix.c:570 #2 0x0000000109c95a1c in iothread_stop #3 0x0000000109bb0874 in monitor_cleanup #4 0x0000000109b55042 in main While the iothread is still in the main loop: Thread 4 #0 0x000003ffad0010e4 in ?? #1 0x000003ffad553958 in g_main_context_iterate.isra.19 #2 0x000003ffad553d90 in g_main_loop_run #3 0x0000000109c9585a in iothread_run at /home/thuth/devel/qemu/iothread.c:74 #4 0x0000000109e94752 in qemu_thread_start at /home/thuth/devel/qemu/util/qemu-thread-posix.c:502 #5 0x000003ffad10825a in start_thread #6 0x000003ffad00dcf2 in thread_start IMHO it's because there's a race between the main thread and iothread when stopping the thread in following sequence: main thread iothread =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D aio_poll() iothread_get_g_main_context set iothread->worker_context iothread_stop schedule iothread_stop_bh execute iothread_stop_bh [1] set iothread->running=3Dfalse (since main_loop=3D=3DNULL so skip to quit main loop. Note: although main_loop is NULL but worker_context is not!) atomic_read(&iothread->worker_context= ) [2] create main_loop object g_main_loop_run() [3] pthread_join() [4] We can see that when execute iothread_stop_bh() at [1] it's possible that main_loop is still NULL because it's only created until the first check of the worker_context later at [2]. Then the iothread will hang in the main loop [3] and it'll starve the main thread too [4]. Here the simple solution should be that we check again the "running" variable before check against worker_context. CC: Thomas Huth CC: Dr. David Alan Gilbert CC: Stefan Hajnoczi CC: Luk=C3=A1=C5=A1 Doktor CC: Markus Armbruster CC: Eric Blake CC: Paolo Bonzini Reported-by: Luk=C3=A1=C5=A1 Doktor Signed-off-by: Peter Xu Tested-by: Thomas Huth Message-id: 20190129051432.22023-1-peterx@redhat.com Signed-off-by: Stefan Hajnoczi --- iothread.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/iothread.c b/iothread.c index 2fb1cdf55d..e615b7ae52 100644 --- a/iothread.c +++ b/iothread.c @@ -63,7 +63,11 @@ static void *iothread_run(void *opaque) while (iothread->running) { aio_poll(iothread->ctx, true); =20 - if (atomic_read(&iothread->worker_context)) { + /* + * We must check the running state again in case it was + * changed in previous aio_poll() + */ + if (iothread->running && atomic_read(&iothread->worker_context)) { GMainLoop *loop; =20 g_main_context_push_thread_default(iothread->worker_context); --=20 2.20.1 From nobody Sun Apr 28 22:25:06 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.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 (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1549944552743516.3744699191499; Mon, 11 Feb 2019 20:09:12 -0800 (PST) Received: from localhost ([127.0.0.1]:60896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPNZ-0000UZ-Ei for importer@patchew.org; Mon, 11 Feb 2019 23:09:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPME-0008Cq-Q2 for qemu-devel@nongnu.org; Mon, 11 Feb 2019 23:07:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtPM7-0007AD-VH for qemu-devel@nongnu.org; Mon, 11 Feb 2019 23:07:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35016) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gtPGv-0002pg-Ne; Mon, 11 Feb 2019 23:02:15 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4DE90811D9; Tue, 12 Feb 2019 04:02:11 +0000 (UTC) Received: from localhost (unknown [10.64.242.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id CFFC9608F3; Tue, 12 Feb 2019 04:02:02 +0000 (UTC) From: Stefan Hajnoczi To: qemu-devel@nongnu.org Date: Tue, 12 Feb 2019 12:01:35 +0800 Message-Id: <20190212040136.30371-3-stefanha@redhat.com> In-Reply-To: <20190212040136.30371-1-stefanha@redhat.com> References: <20190212040136.30371-1-stefanha@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 12 Feb 2019 04:02:11 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 2/3] qemugdb/coroutine: fix arch_prctl has unknown return type X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Laurent Vivier , Thomas Huth , Vladimir Sementsov-Ogievskiy , qemu-block@nongnu.org, Peter Maydell , "Michael S. Tsirkin" , Max Reitz , Stefan Hajnoczi , Paolo Bonzini , Eduardo Habkost Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Vladimir Sementsov-Ogievskiy qemu coroutine command results in following error output: Python Exception 'arch_prctl' has unknown return type; cast the call to its declared return type: Error occurred in Python command: 'arch_prctl' has unknown return type; cast the call to its declared return type Fix it by giving it what it wants: arch_prctl return type. Information on the topic: https://sourceware.org/gdb/onlinedocs/gdb/Calling.html Signed-off-by: Vladimir Sementsov-Ogievskiy Message-id: 20190206151425.105871-1-vsementsov@virtuozzo.com Signed-off-by: Stefan Hajnoczi --- scripts/qemugdb/coroutine.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/qemugdb/coroutine.py b/scripts/qemugdb/coroutine.py index ab699794ab..81f811ac00 100644 --- a/scripts/qemugdb/coroutine.py +++ b/scripts/qemugdb/coroutine.py @@ -22,7 +22,7 @@ def get_fs_base(): pthread_self().''' # %rsp - 120 is scratch space according to the SystemV ABI old =3D gdb.parse_and_eval('*(uint64_t*)($rsp - 120)') - gdb.execute('call arch_prctl(0x1003, $rsp - 120)', False, True) + gdb.execute('call (int)arch_prctl(0x1003, $rsp - 120)', False, True) fs_base =3D gdb.parse_and_eval('*(uint64_t*)($rsp - 120)') gdb.execute('set *(uint64_t*)($rsp - 120) =3D %s' % old, False, True) return fs_base --=20 2.20.1 From nobody Sun Apr 28 22:25:06 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.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 (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1549944334985870.5149240361192; Mon, 11 Feb 2019 20:05:34 -0800 (PST) Received: from localhost ([127.0.0.1]:60851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPK4-0007Eu-VB for importer@patchew.org; Mon, 11 Feb 2019 23:05:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPHg-0005xS-Sm for qemu-devel@nongnu.org; Mon, 11 Feb 2019 23:03:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtPHZ-0003Ot-VK for qemu-devel@nongnu.org; Mon, 11 Feb 2019 23:02:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37228) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gtPHS-00030h-JD; Mon, 11 Feb 2019 23:02:48 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C6605D68A; Tue, 12 Feb 2019 04:02:21 +0000 (UTC) Received: from localhost (unknown [10.64.242.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 48CCF1042555; Tue, 12 Feb 2019 04:02:13 +0000 (UTC) From: Stefan Hajnoczi To: qemu-devel@nongnu.org Date: Tue, 12 Feb 2019 12:01:36 +0800 Message-Id: <20190212040136.30371-4-stefanha@redhat.com> In-Reply-To: <20190212040136.30371-1-stefanha@redhat.com> References: <20190212040136.30371-1-stefanha@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 12 Feb 2019 04:02:21 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 3/3] virtio-blk: cleanup using VirtIOBlock *s and VirtIODevice *vdev X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Laurent Vivier , Thomas Huth , qemu-block@nongnu.org, Peter Maydell , "Michael S. Tsirkin" , Max Reitz , Stefan Hajnoczi , Paolo Bonzini , Stefano Garzarella , Eduardo Habkost Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Stefano Garzarella In several part we still using req->dev or VIRTIO_DEVICE(req->dev) when we have already defined s and vdev pointers: VirtIOBlock *s =3D req->dev; VirtIODevice *vdev =3D VIRTIO_DEVICE(s); Signed-off-by: Stefano Garzarella Reviewed-by: Liam Merwick Message-id: 20190208142347.214815-1-sgarzare@redhat.com Signed-off-by: Stefan Hajnoczi --- hw/block/virtio-blk.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 9a87b3bfac..843bb2bec8 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -63,9 +63,8 @@ static void virtio_blk_req_complete(VirtIOBlockReq *req, = unsigned char status) static int virtio_blk_handle_rw_error(VirtIOBlockReq *req, int error, bool is_read) { - BlockErrorAction action =3D blk_get_error_action(req->dev->blk, - is_read, error); VirtIOBlock *s =3D req->dev; + BlockErrorAction action =3D blk_get_error_action(s->blk, is_read, erro= r); =20 if (action =3D=3D BLOCK_ERROR_ACTION_STOP) { /* Break the link as the next request is going to be parsed from t= he @@ -138,7 +137,7 @@ static void virtio_blk_flush_complete(void *opaque, int= ret) } =20 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK); - block_acct_done(blk_get_stats(req->dev->blk), &req->acct); + block_acct_done(blk_get_stats(s->blk), &req->acct); virtio_blk_free_request(req); =20 out: @@ -513,7 +512,7 @@ static int virtio_blk_handle_request(VirtIOBlockReq *re= q, MultiReqBuffer *mrb) - sizeof(struct virtio_blk_inhdr); iov_discard_back(in_iov, &in_num, sizeof(struct virtio_blk_inhdr)); =20 - type =3D virtio_ldl_p(VIRTIO_DEVICE(req->dev), &req->out.type); + type =3D virtio_ldl_p(vdev, &req->out.type); =20 /* VIRTIO_BLK_T_OUT defines the command direction. VIRTIO_BLK_T_BARRIER * is an optional flag. Although a guest should not send this flag if @@ -522,8 +521,7 @@ static int virtio_blk_handle_request(VirtIOBlockReq *re= q, MultiReqBuffer *mrb) case VIRTIO_BLK_T_IN: { bool is_write =3D type & VIRTIO_BLK_T_OUT; - req->sector_num =3D virtio_ldq_p(VIRTIO_DEVICE(req->dev), - &req->out.sector); + req->sector_num =3D virtio_ldq_p(vdev, &req->out.sector); =20 if (is_write) { qemu_iovec_init_external(&req->qiov, out_iov, out_num); @@ -535,25 +533,23 @@ static int virtio_blk_handle_request(VirtIOBlockReq *= req, MultiReqBuffer *mrb) req->qiov.size / BDRV_SECTOR_SIZE= ); } =20 - if (!virtio_blk_sect_range_ok(req->dev, req->sector_num, - req->qiov.size)) { + if (!virtio_blk_sect_range_ok(s, req->sector_num, req->qiov.size))= { virtio_blk_req_complete(req, VIRTIO_BLK_S_IOERR); - block_acct_invalid(blk_get_stats(req->dev->blk), + block_acct_invalid(blk_get_stats(s->blk), is_write ? BLOCK_ACCT_WRITE : BLOCK_ACCT_RE= AD); virtio_blk_free_request(req); return 0; } =20 - block_acct_start(blk_get_stats(req->dev->blk), - &req->acct, req->qiov.size, + block_acct_start(blk_get_stats(s->blk), &req->acct, req->qiov.size, is_write ? BLOCK_ACCT_WRITE : BLOCK_ACCT_READ); =20 /* merge would exceed maximum number of requests or IO direction * changes */ if (mrb->num_reqs > 0 && (mrb->num_reqs =3D=3D VIRTIO_BLK_MAX_MERG= E_REQS || is_write !=3D mrb->is_write || - !req->dev->conf.request_merging)) { - virtio_blk_submit_multireq(req->dev->blk, mrb); + !s->conf.request_merging)) { + virtio_blk_submit_multireq(s->blk, mrb); } =20 assert(mrb->num_reqs < VIRTIO_BLK_MAX_MERGE_REQS); --=20 2.20.1