From patchwork Tue Feb 12 04:01:34 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Stefan Hajnoczi X-Patchwork-Id: 1040343 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 43z8Bv0mZdz9s4Z for ; Tue, 12 Feb 2019 15:03:03 +1100 (AEDT) Received: from localhost ([127.0.0.1]:60818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPHh-0005bA-5G for incoming@patchwork.ozlabs.org; Mon, 11 Feb 2019 23:03:01 -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) 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?b?THVrw6HFoSBEb2t0b3I=?= , Eduardo Habkost Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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 =========== ============== 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=false (since main_loop==NULL 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áš Doktor CC: Markus Armbruster CC: Eric Blake CC: Paolo Bonzini Reported-by: Lukáš 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); - 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; g_main_context_push_thread_default(iothread->worker_context); From patchwork Tue Feb 12 04:01:35 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Hajnoczi X-Patchwork-Id: 1040346 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 43z8K42yMKz9s4Z for ; Tue, 12 Feb 2019 15:08:24 +1100 (AEDT) Received: from localhost ([127.0.0.1]:60892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPMs-0008EX-Co for incoming@patchwork.ozlabs.org; Mon, 11 Feb 2019 23:08:22 -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) 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+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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 = 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 = gdb.parse_and_eval('*(uint64_t*)($rsp - 120)') gdb.execute('set *(uint64_t*)($rsp - 120) = %s' % old, False, True) return fs_base From patchwork Tue Feb 12 04:01:36 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Hajnoczi X-Patchwork-Id: 1040344 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 43z8Dy6xdDz9s4Z for ; Tue, 12 Feb 2019 15:04:50 +1100 (AEDT) Received: from localhost ([127.0.0.1]:60832 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtPJR-0006o3-0P for incoming@patchwork.ozlabs.org; Mon, 11 Feb 2019 23:04:49 -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) 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+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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 = req->dev; VirtIODevice *vdev = 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 = blk_get_error_action(req->dev->blk, - is_read, error); VirtIOBlock *s = req->dev; + BlockErrorAction action = blk_get_error_action(s->blk, is_read, error); if (action == BLOCK_ERROR_ACTION_STOP) { /* Break the link as the next request is going to be parsed from the @@ -138,7 +137,7 @@ static void virtio_blk_flush_complete(void *opaque, int ret) } 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); out: @@ -513,7 +512,7 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb) - sizeof(struct virtio_blk_inhdr); iov_discard_back(in_iov, &in_num, sizeof(struct virtio_blk_inhdr)); - type = virtio_ldl_p(VIRTIO_DEVICE(req->dev), &req->out.type); + type = virtio_ldl_p(vdev, &req->out.type); /* 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 *req, MultiReqBuffer *mrb) case VIRTIO_BLK_T_IN: { bool is_write = type & VIRTIO_BLK_T_OUT; - req->sector_num = virtio_ldq_p(VIRTIO_DEVICE(req->dev), - &req->out.sector); + req->sector_num = virtio_ldq_p(vdev, &req->out.sector); 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); } - 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_READ); virtio_blk_free_request(req); return 0; } - 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); /* merge would exceed maximum number of requests or IO direction * changes */ if (mrb->num_reqs > 0 && (mrb->num_reqs == VIRTIO_BLK_MAX_MERGE_REQS || is_write != 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); } assert(mrb->num_reqs < VIRTIO_BLK_MAX_MERGE_REQS);