From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33608)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <guangrong.xiao@linux.intel.com>) id 1bNx7A-0007Sv-IB
	for qemu-devel@nongnu.org; Fri, 15 Jul 2016 03:00:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <guangrong.xiao@linux.intel.com>) id 1bNx74-0006Zo-RO
	for qemu-devel@nongnu.org; Fri, 15 Jul 2016 03:00:47 -0400
Received: from mga03.intel.com ([134.134.136.65]:34778)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <guangrong.xiao@linux.intel.com>) id 1bNx74-0006Ze-Jo
	for qemu-devel@nongnu.org; Fri, 15 Jul 2016 03:00:42 -0400
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>
From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Message-ID: <57888925.9040500@linux.intel.com>
Date: Fri, 15 Jul 2016 14:56:37 +0800
MIME-Version: 1.0
In-Reply-To: <0c7f2d23-92c0-8478-7262-6cdd2b800d5d@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1/2] hostmem: fix QEMU crash by 'info
 memdev'
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, Markus Armbruster <armbru@redhat.com>
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



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?