From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fzke7-00043O-NR for qemu-devel@nongnu.org; Tue, 11 Sep 2018 11:32:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fzke1-0000zI-Ov for qemu-devel@nongnu.org; Tue, 11 Sep 2018 11:32:05 -0400 References: <20180910145616.8598-1-famz@redhat.com> <20180910145616.8598-3-famz@redhat.com> <9f4907a3-e96e-131c-a032-1669d0c09bc8@redhat.com> <20180911141245.GQ19292@lemon.usersys.redhat.com> From: Paolo Bonzini Message-ID: <271b24b6-c8eb-1425-3e73-e0ec734bafc6@redhat.com> Date: Tue, 11 Sep 2018 17:30:41 +0200 MIME-Version: 1.0 In-Reply-To: <20180911141245.GQ19292@lemon.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] virtio-scsi/virtio-blk: Disable poll handlers when stopping vq handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, "Michael S. Tsirkin" , peterx@redhat.com, Stefan Hajnoczi On 11/09/2018 16:12, Fam Zheng wrote: > On Tue, 09/11 13:32, Paolo Bonzini wrote: >> On 10/09/2018 16:56, Fam Zheng wrote: >>> We have this unwanted call stack: >>> >>> > ... >>> > #13 0x00005586602b7793 in virtio_scsi_handle_cmd_vq >>> > #14 0x00005586602b8d66 in virtio_scsi_data_plane_handle_cmd >>> > #15 0x00005586602ddab7 in virtio_queue_notify_aio_vq >>> > #16 0x00005586602dfc9f in virtio_queue_host_notifier_aio_poll >>> > #17 0x00005586607885da in run_poll_handlers_once >>> > #18 0x000055866078880e in try_poll_mode >>> > #19 0x00005586607888eb in aio_poll >>> > #20 0x0000558660784561 in aio_wait_bh_oneshot >>> > #21 0x00005586602b9582 in virtio_scsi_dataplane_stop >>> > #22 0x00005586605a7110 in virtio_bus_stop_ioeventfd >>> > #23 0x00005586605a9426 in virtio_pci_stop_ioeventfd >>> > #24 0x00005586605ab808 in virtio_pci_common_write >>> > #25 0x0000558660242396 in memory_region_write_accessor >>> > #26 0x00005586602425ab in access_with_adjusted_size >>> > #27 0x0000558660245281 in memory_region_dispatch_write >>> > #28 0x00005586601e008e in flatview_write_continue >>> > #29 0x00005586601e01d8 in flatview_write >>> > #30 0x00005586601e04de in address_space_write >>> > #31 0x00005586601e052f in address_space_rw >>> > #32 0x00005586602607f2 in kvm_cpu_exec >>> > #33 0x0000558660227148 in qemu_kvm_cpu_thread_fn >>> > #34 0x000055866078bde7 in qemu_thread_start >>> > #35 0x00007f5784906594 in start_thread >>> > #36 0x00007f5784639e6f in clone >>> >>> Avoid it with the aio_disable_external/aio_enable_external pair, so that >>> no vq poll handlers can be called in aio_wait_bh_oneshot. >> >> I don't understand. We are in the vCPU thread, so not in the >> AioContext's home thread. Why is aio_wait_bh_oneshot polling rather >> than going through the aio_wait_bh path? > > What do you mean by 'aio_wait_bh path'? Here is aio_wait_bh_oneshot: Sorry, I meant the "atomic_inc(&wait_->num_waiters);" path. But if this backtrace is obtained without dataplane, that's the answer I was seeking. > void aio_wait_bh_oneshot(AioContext *ctx, QEMUBHFunc *cb, void *opaque) > { > AioWaitBHData data = { > .cb = cb, > .opaque = opaque, > }; > > assert(qemu_get_current_aio_context() == qemu_get_aio_context()); > > aio_bh_schedule_oneshot(ctx, aio_wait_bh, &data); > AIO_WAIT_WHILE(&data.wait, ctx, !data.done); > } > > ctx is qemu_aio_context here, so there's no interaction with IOThread. In this case, it should be okay to have the reentrancy, what is the bug that this patch is fixing? Thanks, Paolo