[dpdk-dev] [PATCH 2/2] test/memzone: handle previously allocated memzones

[Burakov, Anatoly]

On 31-Jan-18 7:51 AM, Phil Yang wrote:
> Hi Anatoly,
> 
> I think your fix is elegant, however you can't grantee it doesn't have dirty memzone remained after memzone autotest.
> What if some existed initial memzone released during the test and some dirty memzone remained. The counter cannot illustrate this state.
> 
> My fix just care about the memzone used in memzone autotest. It is rough but it seems more reliable. 😊
> 
> Thanks,
> Phil Yang

We could combine the approaches. That way, we both ensure that no 
memzones were left in that should've been freed, and that total number 
of memzones didn't change as well (i.e. we didn't allocate/free any 
memzones we weren't supposed to allocate/free).

As i side note, i think making a #define with memzone prefix in your 
patch will work better and will be less copypaste-error-prone in the 
long run.

I will prepare a v2 combining both approaches. Is that OK with you?

> 
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Anatoly Burakov
>> Sent: Saturday, January 27, 2018 1:41 AM
>> To: dev at dpdk.org
>> Cc: radoslaw.biernacki at linaro.org; stable at dpdk.org
>> Subject: [dpdk-dev] [PATCH 2/2] test/memzone: handle previously allocated
>> memzones
>>
>> Currently, memzone autotest expects there to be no memzones present by the
>> time the test is run. Some hardware drivers will allocate memzones for internal
>> use during initialization, resulting in tests failing due to unexpected memzones
>> being allocated before the test was run.
>>
>> Fix this by making callback increment a counter instead. This also doubles as a
>> test for correct operation of memzone_walk().
>>
>> Fixes: 71330483a193 ("test/memzone: fix memory leak")
>> Cc: radoslaw.biernacki at linaro.org
>> Cc: stable at dpdk.org
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>


-- 
Thanks,
Anatoly