From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [Qemu-devel] [PATCH 1/2] hostmem: fix QEMU crash by 'info memdev' Date: Fri, 15 Jul 2016 14:56:37 +0800 Message-ID: <57888925.9040500@linux.intel.com> References: <1468383486-108169-1-git-send-email-guangrong.xiao@linux.intel.com> <945b233e-286f-fc22-8837-761e1ac2e522@redhat.com> <87r3ax6ajl.fsf@dusky.pond.sub.org> <0c7f2d23-92c0-8478-7262-6cdd2b800d5d@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: imammedo@redhat.com, ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, rth@twiddle.net To: Paolo Bonzini , Markus Armbruster Return-path: Received: from mga02.intel.com ([134.134.136.20]:32642 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751756AbcGOHAk (ORCPT ); Fri, 15 Jul 2016 03:00:40 -0400 In-Reply-To: <0c7f2d23-92c0-8478-7262-6cdd2b800d5d@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/13/2016 07:37 PM, Paolo Bonzini wrote: > > > On 13/07/2016 13:29, Markus Armbruster wrote: >>>> I'm curious about one thing. Eric/Markus, it would be nice to open code >>>> the visit of the list with >>>> >>>> visit_start_list(v, name, NULL, 0, &err); >>>> if (err) { >>>> goto out; >>>> } >>>> ... >>>> visit_type_uint16(v, name, &value, &err); >>>> visit_next_list(v, NULL, 0); >>>> ... >>>> visit_end_list(v, NULL); >>>> >>>> We know here that on the other side there is an output visitor. >>>> However, it doesn't work because visit_next_list asserts that tail == >>>> NULL. Would it be easy to support this idiom, and would it make sense >>>> to extend it to other kinds of visitor? >> visit_next_list() asserts tail != NULL because to protect the >> next_list() method. qmp_output_next_list() dereferences tail. >> >> Note that you don't have to call visit_next_list() in a virtual visit. >> For an example, see prop_get_fdt(). Good enough already? > > Yes, definitely! I'm queueing Guangrong's patch because it fixes a > crash and the leak existed before, but without next_list we can indeed > visit a "virtual" list and fix the leak. It can be done during the -rc > period. So you want to build uint16List list and save it as a "virtual" list in host_memory_backend_get_host_nodes(), then its caller can directly fetch this 'virtual' list from the visit?