All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Hedde <damien.hedde@greensocs.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Eduardo Habkost <eduardo@habkost.net>,
	qemu-riscv@nongnu.org, Bin Meng <bin.meng@windriver.com>,
	qemu-devel@nongnu.org,
	Alistair Francis <alistair.francis@wdc.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	paolo Bonzini <pbonzini@redhat.com>,
	Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [PATCH 1/5] hw/riscv/riscv_hart: free the harts array when the object is finalized
Date: Mon, 21 Feb 2022 11:29:11 +0100	[thread overview]
Message-ID: <a2967493-fd00-8f9b-29bd-56baaae9f89a@greensocs.com> (raw)
In-Reply-To: <CAFEAcA_=ORjLU7_T51Jau6DNh8hM_T+XbKbMuh4QjfC03uH4pw@mail.gmail.com>


On 2/18/22 18:46, Peter Maydell wrote:
> On Fri, 18 Feb 2022 at 17:39, Damien Hedde <damien.hedde@greensocs.com> wrote:
>> You're right. I was confused when re-writing the message.
>> This leaks happen on
>> init -> realize-failure -> finalize
>> Because the array is allocated, then every cpu is initialized (and an
>> error failure may happen for any of them).
> 
> "Failure during realize" is one of those cases I don't think we
> handle very well. I'd like to see a view by one of our QOM experts
> on what the best way to handle this is -- should one do the
> cleanup in realize itself, or in instance_finalize? Do the
> sub-objects that are being initialized and realized need to
> be manually cleaned up in the realize-is-failing case, or is
> that part automatic?
> 
> Which is to say that maybe this patch is the best way to do this,
> but it would be nice to be sure about that...
> 

Right now we have only 3 life cycles for coldplug (for hotplug it may be 
a bit different, I don't know but that's not the case of devices in this 
series):
+ user help:       init -> finalize
+ failed creation: init -> realize-failure -> finalize
+ normal cycle:    init -> realize-success -> ... (maybe finalize at 
qemu end)

I'm not even sure unrealize() is called on the normal cycle, at least it 
is not done by DEVICE's finalize() method.

We could try to be clean at the end of realize failure, but anyway it's 
better to free memory at the end. So we'll have to do it in finalize() 
too (or in a unrealize(), if we have guarantee it will be called).
It look simplier to do it in finalize(), it catches all use cases.

Note that we also have two cases of memory allocation:
+ the allocated space hosts some children objects (like in the 
riscv_array of this patch)
+ the allocated space hosts simple C things (other patches of this series)

First case is bit a tricky because obviously we cannot free a child's 
memory until the child is also finalized. To answer your last question, 
cleaning of a child is automatic when the reference is removed at the 
beginning the finalize process of the parent.

Writing the last paragraph makes me realize we have probably no 
guarantee this is the last reference (but it should). So if we want to 
be sure we don't free a still-in-use memory space: we should use 
object_new() instead of object_initialize_child() and let the child free 
it's own memory and avoid this specific issue.

PS: Added qom maintainers/reviewers in cc.
Thanks,
--
Damien


WARNING: multiple messages have this Message-ID (diff)
From: Damien Hedde <damien.hedde@greensocs.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, Palmer Dabbelt <palmer@dabbelt.com>,
	Bin Meng <bin.meng@windriver.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	qemu-riscv@nongnu.org, paolo Bonzini <pbonzini@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>
Subject: Re: [PATCH 1/5] hw/riscv/riscv_hart: free the harts array when the object is finalized
Date: Mon, 21 Feb 2022 11:29:11 +0100	[thread overview]
Message-ID: <a2967493-fd00-8f9b-29bd-56baaae9f89a@greensocs.com> (raw)
In-Reply-To: <CAFEAcA_=ORjLU7_T51Jau6DNh8hM_T+XbKbMuh4QjfC03uH4pw@mail.gmail.com>


On 2/18/22 18:46, Peter Maydell wrote:
> On Fri, 18 Feb 2022 at 17:39, Damien Hedde <damien.hedde@greensocs.com> wrote:
>> You're right. I was confused when re-writing the message.
>> This leaks happen on
>> init -> realize-failure -> finalize
>> Because the array is allocated, then every cpu is initialized (and an
>> error failure may happen for any of them).
> 
> "Failure during realize" is one of those cases I don't think we
> handle very well. I'd like to see a view by one of our QOM experts
> on what the best way to handle this is -- should one do the
> cleanup in realize itself, or in instance_finalize? Do the
> sub-objects that are being initialized and realized need to
> be manually cleaned up in the realize-is-failing case, or is
> that part automatic?
> 
> Which is to say that maybe this patch is the best way to do this,
> but it would be nice to be sure about that...
> 

Right now we have only 3 life cycles for coldplug (for hotplug it may be 
a bit different, I don't know but that's not the case of devices in this 
series):
+ user help:       init -> finalize
+ failed creation: init -> realize-failure -> finalize
+ normal cycle:    init -> realize-success -> ... (maybe finalize at 
qemu end)

I'm not even sure unrealize() is called on the normal cycle, at least it 
is not done by DEVICE's finalize() method.

We could try to be clean at the end of realize failure, but anyway it's 
better to free memory at the end. So we'll have to do it in finalize() 
too (or in a unrealize(), if we have guarantee it will be called).
It look simplier to do it in finalize(), it catches all use cases.

Note that we also have two cases of memory allocation:
+ the allocated space hosts some children objects (like in the 
riscv_array of this patch)
+ the allocated space hosts simple C things (other patches of this series)

First case is bit a tricky because obviously we cannot free a child's 
memory until the child is also finalized. To answer your last question, 
cleaning of a child is automatic when the reference is removed at the 
beginning the finalize process of the parent.

Writing the last paragraph makes me realize we have probably no 
guarantee this is the last reference (but it should). So if we want to 
be sure we don't free a still-in-use memory space: we should use 
object_new() instead of object_initialize_child() and let the child free 
it's own memory and avoid this specific issue.

PS: Added qom maintainers/reviewers in cc.
Thanks,
--
Damien


  reply	other threads:[~2022-02-21 10:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 16:46 [PATCH 0/5] RiscV cleanups for user-related life cycles Damien Hedde
2022-02-18 16:46 ` Damien Hedde
2022-02-18 16:46 ` [PATCH 1/5] hw/riscv/riscv_hart: free the harts array when the object is finalized Damien Hedde
2022-02-18 16:46   ` Damien Hedde
2022-02-18 17:23   ` Peter Maydell
2022-02-18 17:23     ` Peter Maydell
2022-02-18 17:39     ` Damien Hedde
2022-02-18 17:39       ` Damien Hedde
2022-02-18 17:46       ` Peter Maydell
2022-02-18 17:46         ` Peter Maydell
2022-02-21 10:29         ` Damien Hedde [this message]
2022-02-21 10:29           ` Damien Hedde
2022-02-18 16:46 ` [PATCH 2/5] target/riscv: add riscv_cpu_release_claimed_interrupts function Damien Hedde
2022-02-18 16:46   ` Damien Hedde
2022-02-18 16:46 ` [PATCH 3/5] hw/intc/sifive_plic: report errors and free allocated memory Damien Hedde
2022-02-18 16:46   ` Damien Hedde
2022-02-18 16:46 ` [PATCH 4/5] hw/intc/riscv_aclint: swi: " Damien Hedde
2022-02-18 16:46   ` Damien Hedde
2022-02-18 16:46 ` [PATCH 5/5] hw/intc/riscv_aclint: mtimer: " Damien Hedde
2022-02-18 16:46   ` Damien Hedde

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=a2967493-fd00-8f9b-29bd-56baaae9f89a@greensocs.com \
    --to=damien.hedde@greensocs.com \
    --cc=alistair.francis@wdc.com \
    --cc=berrange@redhat.com \
    --cc=bin.meng@windriver.com \
    --cc=eduardo@habkost.net \
    --cc=palmer@dabbelt.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    /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.