All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: liu ping fan <qemulist@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Liu Ping Fan <pingfank@linux.vnet.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [Qemu-devel] [PATCH] qom: Use atomics for object refcounting
Date: Wed, 03 Jul 2013 18:36:19 +0200	[thread overview]
Message-ID: <51D45303.2050100@suse.de> (raw)
In-Reply-To: <CAJnKYQ=tORXm==fNkt2g6Ag1jjOvWyvLMx=Bx_kkysB0KEiSHg@mail.gmail.com>

Am 03.07.2013 03:23, schrieb liu ping fan:
> On Wed, Jul 3, 2013 at 12:36 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>>> Il 02/07/2013 16:47, Anthony Liguori ha scritto:
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> Objects can soon be referenced/dereference outside the BQL. So we need
>>>>> to use atomics in object_ref/unref.
>>>>>
>>>>> Based on patch by Liu Ping Fan.
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> ---
>>>>>  qom/object.c |    5 ++---
>>>>>  1 files changed, 2 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/qom/object.c b/qom/object.c
>>>>> index 803b94b..a76a30b 100644
>>>>> --- a/qom/object.c
>>>>> +++ b/qom/object.c
>>>>> @@ -683,16 +683,15 @@ GSList *object_class_get_list(const char *implements_type,
>>>>>
>>>>>  void object_ref(Object *obj)
>>>>>  {
>>>>> -    obj->ref++;
>>>>> +     __sync_fetch_and_add(&obj->ref, 1);
>>>>>  }
>>>>>
>>>>>  void object_unref(Object *obj)
>>>>>  {
>>>>>      g_assert(obj->ref > 0);
>>>>> -    obj->ref--;
>>>>>
>>>>>      /* parent always holds a reference to its children */
>>>>> -    if (obj->ref == 0) {
>>>>> +    if (__sync_sub_and_fetch(&obj->ref, 1) == 0) {
>>>>>          object_finalize(obj);
>>>>>      }
>>>>>  }
>>>>
>>>> Should we introduce something akin to kref now that referencing counting
>>>> has gotten fancy?
>>>
>>> I'm not a big fan of kref (it seems _too_ thin a wrapper to me, i.e. it
>>> doesn't really wrap enough to be useful), but I wouldn't oppose it if
>>> someone else does it.
>>
>> I had honestly hoped Object was light enough to be used for this
>> purpose.  What do you think?
>>
> I think it is a good idea. So we can consider the object_finalize() as
> the place to release everything. Take the DeviceState as example, we
> will have
> 
> -- >8 --
> Subject: [PATCH] qom: delay DeviceState destructor until object finialize
> 
>     Until refcnt->0, we know that the DeviceState can be safely dropped,
>     so put the destructor there.
> 
>     Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>

It would be nice to get CC'ed on such proposals. :)

> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index 6985ad8..1f4e5d8 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -794,9 +794,7 @@ static void device_unparent(Object *obj)
>          bus = QLIST_FIRST(&dev->child_bus);
>          qbus_free(bus);
>      }
> -    if (dev->realized) {
> -        object_property_set_bool(obj, false, "realized", NULL);
> -    }
> +
>      if (dev->parent_bus) {
>          bus_remove_child(dev->parent_bus, dev);
>          object_unref(OBJECT(dev->parent_bus));
> diff --git a/qom/object.c b/qom/object.c
> index 803b94b..2c945f0 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -393,6 +393,7 @@ static void object_finalize(void *data)
>      Object *obj = data;
>      TypeImpl *ti = obj->class->type;
> 
> +    object_property_set_bool(obj, false, "realized", NULL);

This is incorrect since we specifically only have "realized" for
devices, not for all QOM objects.

If we want to move it to the finalizer you'll need to use
.instance_finalize on the device type in hw/core/qdev.c.
However the derived type's finalizer is run before its parent's, which
may lead to realized = false accessing freed memory.

Regards,
Andreas

>      object_deinit(obj, ti);
>      object_property_del_all(obj);
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2013-07-03 16:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02  9:36 [Qemu-devel] [PATCH] qom: Use atomics for object refcounting Jan Kiszka
2013-07-02 11:15 ` Andreas Färber
2013-07-02 11:28   ` Paolo Bonzini
2013-07-02 11:44     ` Jan Kiszka
2013-07-02 11:49       ` Paolo Bonzini
2013-07-02 11:52         ` Jan Kiszka
2013-07-02 12:00           ` Paolo Bonzini
2013-07-02 14:47 ` Anthony Liguori
2013-07-02 15:33   ` Paolo Bonzini
2013-07-02 16:36     ` Anthony Liguori
2013-07-03  1:23       ` liu ping fan
2013-07-03 16:36         ` Andreas Färber [this message]
2013-07-04  4:46           ` liu ping fan
2013-07-04  5:43             ` Andreas Färber
2013-07-04  7:21               ` liu ping fan
2013-07-04  7:59       ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51D45303.2050100@suse.de \
    --to=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=jan.kiszka@siemens.com \
    --cc=pbonzini@redhat.com \
    --cc=pingfank@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemulist@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.