From patchwork Fri May 26 20:21:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Wolf X-Patchwork-Id: 9751129 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 36AE460246 for ; Fri, 26 May 2017 20:26:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2987A27F90 for ; Fri, 26 May 2017 20:26:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1E63228347; Fri, 26 May 2017 20:26:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id AC32C27F90 for ; Fri, 26 May 2017 20:26:38 +0000 (UTC) Received: from localhost ([::1]:38287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dELoj-0007J2-RM for patchwork-qemu-devel@patchwork.kernel.org; Fri, 26 May 2017 16:26:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dELkk-0004ER-JR for qemu-devel@nongnu.org; Fri, 26 May 2017 16:22:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dELkj-0005Av-Qn for qemu-devel@nongnu.org; Fri, 26 May 2017 16:22:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57098) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dELkh-0005A4-H9; Fri, 26 May 2017 16:22:27 -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 78D6919CBD1; Fri, 26 May 2017 20:22:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 78D6919CBD1 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kwolf@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 78D6919CBD1 Received: from noname.redhat.com (ovpn-116-43.ams2.redhat.com [10.36.116.43]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B9F61713B; Fri, 26 May 2017 20:22:22 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Fri, 26 May 2017 22:21:42 +0200 Message-Id: <1495830130-30611-2-git-send-email-kwolf@redhat.com> In-Reply-To: <1495830130-30611-1-git-send-email-kwolf@redhat.com> References: <1495830130-30611-1-git-send-email-kwolf@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.29]); Fri, 26 May 2017 20:22:26 +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] [PATCH 01/29] qed: Use bottom half to resume waiting requests 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: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, mreitz@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP The qed driver serialises allocating write requests. When the active allocation is finished, the AIO callback is called, but after this, the next allocating request is immediately processed instead of leaving the coroutine. Resuming another allocation request in the same request coroutine means that the request now runs in the wrong coroutine. The following is one of the possible effects of this: The completed request will generally reenter its request coroutine in a bottom half, expecting that it completes the request in bdrv_driver_pwritev(). However, if the second request actually yielded before leaving the coroutine, the reused request coroutine is in an entirely different place and is reentered prematurely. Not a good idea. Let's make sure that we exit the coroutine after completing the first request by resuming the next allocating request only with a bottom half. Signed-off-by: Kevin Wolf Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi --- block/qed.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/block/qed.c b/block/qed.c index 8d899fd..a837a28 100644 --- a/block/qed.c +++ b/block/qed.c @@ -967,6 +967,11 @@ static void qed_aio_complete_bh(void *opaque) qed_release(s); } +static void qed_resume_alloc_bh(void *opaque) +{ + qed_aio_start_io(opaque); +} + static void qed_aio_complete(QEDAIOCB *acb, int ret) { BDRVQEDState *s = acb_to_s(acb); @@ -995,10 +1000,12 @@ static void qed_aio_complete(QEDAIOCB *acb, int ret) * requests multiple times but rather finish one at a time completely. */ if (acb == QSIMPLEQ_FIRST(&s->allocating_write_reqs)) { + QEDAIOCB *next_acb; QSIMPLEQ_REMOVE_HEAD(&s->allocating_write_reqs, next); - acb = QSIMPLEQ_FIRST(&s->allocating_write_reqs); - if (acb) { - qed_aio_start_io(acb); + next_acb = QSIMPLEQ_FIRST(&s->allocating_write_reqs); + if (next_acb) { + aio_bh_schedule_oneshot(bdrv_get_aio_context(acb->common.bs), + qed_resume_alloc_bh, next_acb); } else if (s->header.features & QED_F_NEED_CHECK) { qed_start_need_check_timer(s); }