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-boun...@dpdk.org] On Behalf Of Anatoly Burakov
Sent: Saturday, January 27, 2018 1:41 AM
To: dev@dpdk.org
Cc: radoslaw.bierna...@linaro.org; sta...@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.bierna...@linaro.org
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov <anatoly.bura...@intel.com>
--
Thanks,
Anatoly
