From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id EF85BA05D3 for ; Tue, 23 Apr 2019 10:29:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BFBBC1B48F; Tue, 23 Apr 2019 10:29:11 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 828421B453; Tue, 23 Apr 2019 10:29:10 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2019 01:29:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,385,1549958400"; d="scan'208";a="167056466" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.1.168]) ([10.252.1.168]) by fmsmga001.fm.intel.com with ESMTP; 23 Apr 2019 01:29:08 -0700 To: Herakliusz Lipiec Cc: dev@dpdk.org, jianfeng.tan@intel.com, stable@dpdk.org References: <20190417144100.22548-1-herakliusz.lipiec@intel.com> From: "Burakov, Anatoly" Message-ID: <76414190-bc1a-f375-1f24-084403a52b5c@intel.com> Date: Tue, 23 Apr 2019 09:29:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190417144100.22548-1-herakliusz.lipiec@intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 4/8] ipc: fix vfio memleak X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190423082908.8ljcqB_MOm5LxmoLEa32axEmuFBGb2r5mtEoOy_mVFM@z> On 17-Apr-19 3:41 PM, Herakliusz Lipiec wrote: > When sending multiple requests, rte_mp_request_sync > can succeed sending a few of those requests, but then > fail on a later one and in the end return with rc=-1. > The upper layers - e.g. device hotplug - currently > handles this case as if no messages were sent and no > memory for response buffers was allocated, which is > not true. Fixed by always freeing reply message buffers. This commit message is duplicated in multiple commits, and does not really describe the problem you're fixing. Since you've already updated the IPC API docs to ask caller to free even in case of failure, i think here (and in other similar patches) it is sufficient to just say something like: When sending synchronous IPC requests, the caller must free the response buffer even if the request returned failure. Fix the code to correctly use the IPC API. > > Fixes: 83a73c5fef66 ("vfio: use generic multi-process channel") > Cc: jianfeng.tan@intel.com > Cc: stable@dpdk.org > Signed-off-by: Herakliusz Lipiec > --- For actual code, Acked-by: Anatoly Burakov -- Thanks, Anatoly