From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38214)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1YxEyb-00036V-8G
	for qemu-devel@nongnu.org; Tue, 26 May 2015 09:33:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1YxEya-00049Q-Cr
	for qemu-devel@nongnu.org; Tue, 26 May 2015 09:33:01 -0400
Message-ID: <556475BD.50401@redhat.com>
Date: Tue, 26 May 2015 15:31:41 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1429964684-23872-1-git-send-email-aik@ozlabs.ru>
	<1429964684-23872-7-git-send-email-aik@ozlabs.ru>
	<55633A54.8080807@ozlabs.ru>
	<20150526024628.GA30620@voom.redhat.com>
	<5564359A.2070009@redhat.com> <556447BB.9000802@ozlabs.ru>
	<55644819.3000003@redhat.com> <55646803.8040007@ozlabs.ru>
	<55646C18.4000303@redhat.com> <5564750C.8000100@ozlabs.ru>
In-Reply-To: <5564750C.8000100@ozlabs.ru>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce
 "enabled" state for TCE table
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: Alexey Kardashevskiy <aik@ozlabs.ru>, David Gibson <david@gibson.dropbear.id.au>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>, Alex Williamson <alex.williamson@redhat.com>, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>



On 26/05/2015 15:28, Alexey Kardashevskiy wrote:
> 
> My initial concern was if I can or cannot do:
> 
> memory_region_init_iommu + memory_region_add_subregion
> and
> memory_region_del_subregion + object_unref
> 
> outside of init/realize/unrealize/finalize.
> 
> You said I cannot do unparenting but as I am not doing this (and I just
> do unref()) - I am fine. That's what I meant.

Well, if you do the above you have two different bugs:

1) you leak the original child property

2) you initialize the second region on top of the first, so you have two
regions pointing to the same memory

This is even worse than unparenting :) and would have been wrong even
without the RCU changes.

Paolo