From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51181)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1aIxcc-00086a-RT
	for qemu-devel@nongnu.org; Tue, 12 Jan 2016 07:00:26 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1aIxcX-0000HJ-PP
	for qemu-devel@nongnu.org; Tue, 12 Jan 2016 07:00:22 -0500
Received: from mx1.redhat.com ([209.132.183.28]:46013)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1aIxcX-0000Gn-KV
	for qemu-devel@nongnu.org; Tue, 12 Jan 2016 07:00:17 -0500
References: <VI1PR05MB111929067D12C8996C291CFDD4FE0@VI1PR05MB1119.eurprd05.prod.outlook.com>
	<5686FFAF.3070205@redhat.com> <1452595481.13986.144.camel@oracle.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <5694EACB.8040009@redhat.com>
Date: Tue, 12 Jan 2016 13:00:11 +0100
MIME-Version: 1.0
In-Reply-To: <1452595481.13986.144.camel@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] Possible reference leak in device_set_realized(...)
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: Knut Omang <knut.omang@oracle.com>, Ilya Lesokhin <ilyal@mellanox.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Haggai Eran <haggaie@mellanox.com>



On 12/01/2016 11:44, Knut Omang wrote:
> On Fri, 2016-01-01 at 23:37 +0100, Paolo Bonzini wrote:
>>
>> On 31/12/2015 19:13, Ilya Lesokhin wrote:
>>> I was able to overcome this issue by calling object_unparent on my
>>> device but I=E2=80=99m not sure that the correct way of fixing it.
>>
>> Yes, it's definitely the right way to fix it.
>=20
> Sorry for the late follow-up on this one, but I had to find some more
> time to spend with the code (and with valgrind too) to understand
> better/verify what was going on in the qdev/qom layers.
>=20
> In the SR/IOV patch the object is created by pci_create.
> Since there is no corresponding pci_delete, I assume this means that
> the correct way to clean up from pci_create is simply a call to
> object_unparent() as you indicate, and this is what is missing from the
> patch set.
>=20
> So the full setup/teardown sequence per VF then becomes:
>=20
> pci_create(...)
> <realize>
>=20
> <unrealize>
> object_unparent(...)

Almost: object_unparent takes care of unrealizing.

Paolo