From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id CEC83952 for ; Fri, 1 Apr 2016 11:01:54 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 01 Apr 2016 02:01:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,426,1455004800"; d="scan'208";a="923248423" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga001.jf.intel.com with ESMTP; 01 Apr 2016 02:01:54 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 1 Apr 2016 10:01:52 +0100 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.174]) by IRSMSX156.ger.corp.intel.com ([169.254.3.132]) with mapi id 14.03.0248.002; Fri, 1 Apr 2016 10:01:52 +0100 From: "Burakov, Anatoly" To: Mauricio Vasquez B CC: "dev@dpdk.org" Thread-Topic: [PATCH] ivshmem: fix race condition Thread-Index: AQHRi+7dOukKo8+Mt0yZkxqyq+hIV590zRmw Date: Fri, 1 Apr 2016 09:01:51 +0000 Message-ID: References: <1459498608-10789-1-git-send-email-mauricio.vasquezbernal@studenti.polito.it> In-Reply-To: <1459498608-10789-1-git-send-email-mauricio.vasquezbernal@studenti.polito.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDQ5YjMzNTYtZDdiNC00NmQ4LWI2ZGQtZmJhMTM1ODA5MjA2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik90djFpTXRuYUw3YmNFMlZybXRaQWVvSTJac21JSEY3MFNEejIzekp6MUU9In0= x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] ivshmem: fix race condition 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: Fri, 01 Apr 2016 09:01:55 -0000 Hi Mauricio, > The memory zone could be freed just after adding it to the metadata > file and just before marking it as not freeable. > This patch changes the locking logic in order to prevent it. Just a nit: if the stated purpose of the patch is to prevent the memzone fr= ee before adding it to metadata, then it probably should check if the memzone wasn't freed before we got the lock (or if it's a valid memzone in the firs= t place). Probably just checking if the virtual address of the memzone isn't 0 would = be enough. Otherwise looks fine to me. Thanks, Anatoly