From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id D88A7C1C6 for ; Thu, 9 Jun 2016 10:03:17 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bAuy7-0001wx-15; Thu, 09 Jun 2016 10:05:35 +0200 To: Sergio Gonzalez Monroy , dev@dpdk.org References: <1465398627-35022-1-git-send-email-sergio.gonzalez.monroy@intel.com> <57586EAC.7090304@6wind.com> <1cafd17e-ffe1-83cc-e745-d3dedc5d44cf@intel.com> From: Olivier Matz Message-ID: <575922BF.8040509@6wind.com> Date: Thu, 9 Jun 2016 10:03:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <1cafd17e-ffe1-83cc-e745-d3dedc5d44cf@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mempool: fix local cache initialization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 08:03:18 -0000 Hi Sergio, On 06/09/2016 09:57 AM, Sergio Gonzalez Monroy wrote: > Hi Olivier, > > On 08/06/2016 20:14, Olivier Matz wrote: >> Hi Sergio, >> >> Good catch, thanks. The patch looks ok, just few comments >> on the commit log: >> >> On 06/08/2016 05:10 PM, Sergio Gonzalez Monroy wrote: >>> The mempool local cache is not being initialize properly leading to >> 'initialize' -> 'initialized' ? >> and maybe 'is not being' -> 'was not' ? >> >>> undefined behavior in cases where the allocated memory was used and left >>> with data. >>> >>> Fixes: af75078fece3 ("first public release") >> I think it fixes this one instead: >> >> 213af31e0960 ("mempool: reduce structure size if no cache needed") > > Fair enough, I thought the issue was there as we never > initialized/zeroed the local cache > on mempool creation. Usually we would have allocated all mempools on > init (or close) > and that would be it (initially all memory would be zeroed), but I think > you could still > manage to reproduce the problem if somehow you where to do something like: > rte_malloc(), rte_free(), rte_mempool_create() and the memory was the > one we got > with malloc and never gets zeroed again. Before Keith's commit (213af31e0960), the local cache was initialized when doing the memset() because it was included in the mempool structure. So I think the problem did not exist before this patch. Or did I miss something in your explanation? Regards, Olivier