[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 0/6] delay timer_new from init to realize to fix memleaks.
From: |
Pan Nengyuan |
Subject: |
Re: [PATCH v3 0/6] delay timer_new from init to realize to fix memleaks. |
Date: |
Tue, 3 Mar 2020 09:26:09 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 |
On 3/2/2020 9:21 PM, Peter Maydell wrote:
> On Thu, 27 Feb 2020 at 02:35, Pan Nengyuan <address@hidden> wrote:
>>
>> This series delay timer_new from init into realize to avoid memleaks when we
>> call 'device_list_properties'.
>> And do timer_free only in s390x_cpu_finalize because it's hotplugable.
>> However, It's not valid in mos6522
>> if we move timer_new from init to realize, because it's never called at all.
>> So we also add calls to mos6522_realize()
>> in mac_via_realize to make this move to be valid.
>>
>> v1:
>> - Delay timer_new() from init() to realize() to fix memleaks.
>> v2:
>> - Similarly to other cleanups, move timer_new into realize in
>> target/s390x/cpu.c (Suggested by Philippe Mathieu-Daudé).
>> - Send these two patches as a series instead of send each as a single
>> patch but with wrong subject in v1.
>> v3:
>> - It's not valid in mos6522 if we move timer_new from init to realize,
>> because it's never called at all.
>> Thus, we remove null check in reset, and add calls to mos6522_realize()
>> in mac_via_realize to make this move to be valid.
>> - split patch by device to make it more clear.
>
> Hi; I've applied patches 2, 3, 4 and 6 to target-arm.next,
> since I think those ones are OK and they're all arm related.
>
> You've already got review comment for patch 1 (s390)
> and 5 (m68k mac_via/mos6522).
Fine, thanks.
>
> thanks
> -- PMM
>