From nobody Thu Dec 18 13:37:35 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1496864834366768.6637400420267; Wed, 7 Jun 2017 12:47:14 -0700 (PDT) Received: from localhost ([::1]:45592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dIfOz-0008Im-56 for importer@patchew.org; Wed, 07 Jun 2017 14:09:53 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dIfNB-0006xa-7d for qemu-devel@nongnu.org; Wed, 07 Jun 2017 14:08:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dIfN7-0004DI-1s for qemu-devel@nongnu.org; Wed, 07 Jun 2017 14:08:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35142) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dIfN6-0004D0-Ph for qemu-devel@nongnu.org; Wed, 07 Jun 2017 14:07:56 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DD4163D970; Wed, 7 Jun 2017 18:07:55 +0000 (UTC) Received: from localhost (ovpn-117-84.ams2.redhat.com [10.36.117.84]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7DE2217114; Wed, 7 Jun 2017 18:07:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DD4163D970 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=stefanha@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DD4163D970 From: Stefan Hajnoczi To: Date: Wed, 7 Jun 2017 19:07:35 +0100 Message-Id: <20170607180736.11011-5-stefanha@redhat.com> In-Reply-To: <20170607180736.11011-1-stefanha@redhat.com> References: <20170607180736.11011-1-stefanha@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 07 Jun 2017 18:07:56 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL for-2.9 4/5] coroutine-lock: do not touch coroutine after another one has been entered 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 , Peter Maydell , Fam Zheng , Roman Pen , Stefan Hajnoczi , Paolo Bonzini Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Roman Pen Submission of requests on linux aio is a bit tricky and can lead to requests completions on submission path: 44713c9e8547 ("linux-aio: Handle io_submit() failure gracefully") 0ed93d84edab ("linux-aio: process completions from ioq_submit()") That means that any coroutine which has been yielded in order to wait for completion can be resumed from submission path and be eventually terminated (freed). The following use-after-free crash was observed when IO throttling was enabled: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f5813dff700 (LWP 56417)] virtqueue_unmap_sg (elem=3D0x7f5804009a30, len=3D1, vq=3D) = at virtio.c:252 (gdb) bt #0 virtqueue_unmap_sg (elem=3D0x7f5804009a30, len=3D1, vq=3D) at virtio.c:252 ^^^^^^^^^^^^^^ remember the address #1 virtqueue_fill (vq=3D0x5598b20d21b0, elem=3D0x7f5804009a30, len=3D1, i= dx=3D0) at virtio.c:282 #2 virtqueue_push (vq=3D0x5598b20d21b0, elem=3Delem@entry=3D0x7f5804009a3= 0, len=3D) at virtio.c:308 #3 virtio_blk_req_complete (req=3Dreq@entry=3D0x7f5804009a30, status=3Dst= atus@entry=3D0 '\000') at virtio-blk.c:61 #4 virtio_blk_rw_complete (opaque=3D, ret=3D0) at virtio-b= lk.c:126 #5 blk_aio_complete (acb=3D0x7f58040068d0) at block-backend.c:923 #6 coroutine_trampoline (i0=3D, i1=3D) at c= oroutine-ucontext.c:78 (gdb) p * elem $8 =3D {index =3D 77, out_num =3D 2, in_num =3D 1, in_addr =3D 0x7f5804009ad8, out_addr =3D 0x7f5804009ae0, in_sg =3D 0x0, out_sg =3D 0x7f5804009a50} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 'in_sg' and 'out_sg' are invalid. e.g. it is impossible that 'in_sg' is zero, instead its value must be equal to: (gdb) p/x 0x7f5804009ad8 + sizeof(elem->in_addr[0]) + 2 * sizeof(ele= m->out_addr[0]) $26 =3D 0x7f5804009af0 Seems 'elem' was corrupted. Meanwhile another thread raised an abort: Thread 12 (Thread 0x7f57f2ffd700 (LWP 56426)): #0 raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 qemu_coroutine_enter (co=3D0x7f5804009af0) at qemu-coroutine.c:113 #3 qemu_co_queue_run_restart (co=3D0x7f5804009a30) at qemu-coroutine-lock= .c:60 #4 qemu_coroutine_enter (co=3D0x7f5804009a30) at qemu-coroutine.c:119 ^^^^^^^^^^^^^^^^^^ WTF?? this is equal to elem from crashed thread #5 qemu_co_queue_run_restart (co=3D0x7f57e7f16ae0) at qemu-coroutine-lock= .c:60 #6 qemu_coroutine_enter (co=3D0x7f57e7f16ae0) at qemu-coroutine.c:119 #7 qemu_co_queue_run_restart (co=3D0x7f5807e112a0) at qemu-coroutine-lock= .c:60 #8 qemu_coroutine_enter (co=3D0x7f5807e112a0) at qemu-coroutine.c:119 #9 qemu_co_queue_run_restart (co=3D0x7f5807f17820) at qemu-coroutine-lock= .c:60 #10 qemu_coroutine_enter (co=3D0x7f5807f17820) at qemu-coroutine.c:119 #11 qemu_co_queue_run_restart (co=3D0x7f57e7f18e10) at qemu-coroutine-lock= .c:60 #12 qemu_coroutine_enter (co=3D0x7f57e7f18e10) at qemu-coroutine.c:119 #13 qemu_co_enter_next (queue=3Dqueue@entry=3D0x5598b1e742d0) at qemu-coro= utine-lock.c:106 #14 timer_cb (blk=3D0x5598b1e74280, is_write=3D) at throttl= e-groups.c:419 Crash can be explained by access of 'co' object from the loop inside qemu_co_queue_run_restart(): while ((next =3D QSIMPLEQ_FIRST(&co->co_queue_wakeup))) { QSIMPLEQ_REMOVE_HEAD(&co->co_queue_wakeup, co_queue_next); ^^^^^^^^^^^^^^^^^^^^ on each iteration 'co' is accessed, but 'co' can be already freed qemu_coroutine_enter(next); } When 'next' coroutine is resumed (entered) it can in its turn resume 'co', and eventually free it. That's why we see 'co' (which was freed) has the same address as 'elem' from the first backtrace. The fix is obvious: use temporary queue and do not touch coroutine after first qemu_coroutine_enter() is invoked. The issue is quite rare and happens every ~12 hours on very high IO and CPU load (building linux kernel with -j512 inside guest) when IO throttling is enabled. With the fix applied guest is running ~35 hours and is still alive so far. Signed-off-by: Roman Pen Reviewed-by: Stefan Hajnoczi Message-id: 20170601160847.23720-1-roman.penyaev@profitbricks.com Cc: Paolo Bonzini Cc: Fam Zheng Cc: Stefan Hajnoczi Cc: Kevin Wolf Cc: qemu-devel@nongnu.org Signed-off-by: Stefan Hajnoczi --- util/qemu-coroutine-lock.c | 19 +++++++++++++++++-- util/qemu-coroutine.c | 5 +++++ 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/util/qemu-coroutine-lock.c b/util/qemu-coroutine-lock.c index 6328eed..b44b5d5 100644 --- a/util/qemu-coroutine-lock.c +++ b/util/qemu-coroutine-lock.c @@ -77,10 +77,25 @@ void coroutine_fn qemu_co_queue_wait(CoQueue *queue, Co= Mutex *mutex) void qemu_co_queue_run_restart(Coroutine *co) { Coroutine *next; + QSIMPLEQ_HEAD(, Coroutine) tmp_queue_wakeup =3D + QSIMPLEQ_HEAD_INITIALIZER(tmp_queue_wakeup); =20 trace_qemu_co_queue_run_restart(co); - while ((next =3D QSIMPLEQ_FIRST(&co->co_queue_wakeup))) { - QSIMPLEQ_REMOVE_HEAD(&co->co_queue_wakeup, co_queue_next); + + /* Because "co" has yielded, any coroutine that we wakeup can resume i= t. + * If this happens and "co" terminates, co->co_queue_wakeup becomes + * invalid memory. Therefore, use a temporary queue and do not touch + * the "co" coroutine as soon as you enter another one. + * + * In its turn resumed "co" can pupulate "co_queue_wakeup" queue with + * new coroutines to be woken up. The caller, who has resumed "co", + * will be responsible for traversing the same queue, which may cause + * a different wakeup order but not any missing wakeups. + */ + QSIMPLEQ_CONCAT(&tmp_queue_wakeup, &co->co_queue_wakeup); + + while ((next =3D QSIMPLEQ_FIRST(&tmp_queue_wakeup))) { + QSIMPLEQ_REMOVE_HEAD(&tmp_queue_wakeup, co_queue_next); qemu_coroutine_enter(next); } } diff --git a/util/qemu-coroutine.c b/util/qemu-coroutine.c index 486af9a..d6095c1 100644 --- a/util/qemu-coroutine.c +++ b/util/qemu-coroutine.c @@ -126,6 +126,11 @@ void qemu_aio_coroutine_enter(AioContext *ctx, Corouti= ne *co) =20 qemu_co_queue_run_restart(co); =20 + /* Beware, if ret =3D=3D COROUTINE_YIELD and qemu_co_queue_run_restart= () + * has started any other coroutine, "co" might have been reentered + * and even freed by now! So be careful and do not touch it. + */ + switch (ret) { case COROUTINE_YIELD: return; --=20 2.9.4