qemu-arm
[Top][All Lists]
Advanced

[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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]