From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id EA7517CEB for ; Fri, 27 Apr 2018 17:39:37 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2018 08:39:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,335,1520924400"; d="scan'208";a="51350120" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.25.158]) ([10.252.25.158]) by orsmga001.jf.intel.com with ESMTP; 27 Apr 2018 08:39:34 -0700 To: Bruce Richardson Cc: dev@dpdk.org, thomas@monjalon.net References: <4d15c97e68ce89c0915935c6c04099a9eb950232.1524650130.git.anatoly.burakov@intel.com> <20180427151831.GD80648@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 27 Apr 2018 16:39:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180427151831.GD80648@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 4/9] mem: fix potential resource leak 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: , X-List-Received-Date: Fri, 27 Apr 2018 15:39:38 -0000 On 27-Apr-18 4:18 PM, Bruce Richardson wrote: > On Wed, Apr 25, 2018 at 10:56:42AM +0100, Anatoly Burakov wrote: >> We close fd if we managed to find it in the list of allocated >> segment lists (which should always be the case under normal >> conditions), but if we didn't, the fd was leaking. Close it if >> we couldn't find it in the segment list. This is not an issue >> as if the segment is zero length, we're getting rid of it >> anyway, so there's no harm in not storing the fd anywhere. >> >> Coverity issue: 272568 >> > > This coverity issue indicates two resource leaks, while I think this patch > only closes one of them. The other issue is actually a false positive. We couldn't have gotten the fd if there wasn't a tailq entry for that fd, but if we don't resize and remove the file, we want to keep the fd. So the "int fd" goes out of scope, but actually it's stored in the tailq, and thus doesn't leak. -- Thanks, Anatoly