From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6E630A0565; Tue, 10 Mar 2020 10:32:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C42E31C00E; Tue, 10 Mar 2020 10:32:08 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id C336F1C002 for ; Tue, 10 Mar 2020 10:32:06 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2020 02:32:05 -0700 X-IronPort-AV: E=Sophos;i="5.70,536,1574150400"; d="scan'208";a="353579606" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.86.38]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2020 02:32:04 -0700 Date: Tue, 10 Mar 2020 09:31:56 +0000 From: Bruce Richardson To: Jim Harris Cc: dev@dpdk.org Message-ID: <20200310093156.GA1915@bricha3-MOBL.ger.corp.intel.com> References: <20200309100025.9022-1-james.r.harris@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200309100025.9022-1-james.r.harris@intel.com> Subject: Re: [dpdk-dev] [PATCH] contigmem: cleanup properly when load fails 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" On Mon, Mar 09, 2020 at 03:00:25AM -0700, Jim Harris wrote: > If contigmem is not able to allocate all of the > requested buffers, it frees whatever buffers were > able to be allocated up until that point. > > But the pointers are not set to NULL in that case. > After the load fails, the FreeBSD kernel will > immediately call the contigmem unload handler, which > tries to free the buffers again since the pointers > were not set to NULL. > > It's not clear that we should just rely on the unload > handler getting called after load failure. So let's > keep the existing cleanup code in the load handler, > but explicitly set the pointers to NULL after freeing > them. > > Signed-off-by: Jim Harris > --- Acked-by: Bruce Richardson