From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPTEh-0002tA-1y for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:30:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPTEb-0007nG-2z for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:30:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPTEa-0007nA-Tj for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:30:45 -0400 References: <1468923921-24868-1-git-send-email-roman.penyaev@profitbricks.com> <1468923921-24868-4-git-send-email-roman.penyaev@profitbricks.com> <89cdbaae-9c8c-dda9-6574-84d3633e4a1c@redhat.com> From: Paolo Bonzini Message-ID: <7f6b108c-1ae6-fded-f252-d0aefaf3d568@redhat.com> Date: Tue, 19 Jul 2016 13:30:41 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] linux-aio: process completions from ioq_submit() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roman Penyaev Cc: Stefan Hajnoczi , qemu-devel On 19/07/2016 13:18, Roman Penyaev wrote: >> > No need for this new field. You can just do nothing here and check >> > laiocb.ret =3D=3D -EINPROGRESS here in laio_co_submit. >=20 > I have thought but did not like it, because we depend on the value, > which kernel writes there. (The kernel actually writes to ev->res). > If kernel by chance writes -EINPROGRESS > (whatever that means, bug in some ll driver?) we are screwed up. > But probably that is my paranoia. Understood. However, QEMU relies elsewhere on EINPROGRESS not being returned for file I/O, so I think it's safe. > Also, I hope (I do not know how to reproduce this, virtio_blk does not = nest), > that we are allowed to nest (calling aio_poll() and all this machinery)= from > co-routine. Hmm, good question. The nesting scenario originally happened exactly from a coroutine (commit_run), but I suspect that it cannot happen anymore since we've introduced block_job_defer_to_main_loop and bdrv_co_drain. In any case your patch wouldn't change that. Paolo > Are we? We can lead to deep nesting inside the following sequence: > ioq_submit() -> complete() -> aio_poll() -> ioq_submit() -> complete() = ... > but that can happen of course even without this patch. I would say thi= s nesting > is a clumsy stuff. Paolo