From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0073.outbound.protection.outlook.com [104.47.32.73]) by dpdk.org (Postfix) with ESMTP id CFBB22BA1 for ; Sat, 18 Mar 2017 08:02:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6PFlZabkEQ/VP1ANMyPK9TFohfEZKuvujabktehTqQs=; b=aueX/l8g0c1zljvdZmaky4r4QJfbkU0HdzFVxMtt6aNSwxd1u/QvD4nUOoWSJwgcF3K4DyoPI23A1X576ysasBltolU8mjfs1tzcdWnedJagKD67HGxNEZ7bDyNku3yrjjzHiRM+PUPuGWzkJpyErQQVLNxEtAiE0oL2Nbpc0WE= Received: from BLUPR0701MB1572.namprd07.prod.outlook.com (10.163.84.146) by BLUPR0701MB1572.namprd07.prod.outlook.com (10.163.84.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Sat, 18 Mar 2017 07:02:20 +0000 Received: from BLUPR0701MB1572.namprd07.prod.outlook.com ([10.163.84.146]) by BLUPR0701MB1572.namprd07.prod.outlook.com ([10.163.84.146]) with mapi id 15.01.0977.017; Sat, 18 Mar 2017 07:02:20 +0000 From: "Mody, Rasesh" To: Ferruh Yigit , "dev@dpdk.org" CC: Dept-Eng DPDK Dev Thread-Topic: [dpdk-dev] [PATCH 02/21] net/qede/base: fix to set pointers to NULL after freeing Thread-Index: AQHSkM5pOrILJ+ikikSWgNYRrkfFMKGBia8AgBi+SuA= Date: Sat, 18 Mar 2017 07:02:19 +0000 Message-ID: References: <1488181923-9649-1-git-send-email-rasesh.mody@cavium.com> <1488181923-9649-2-git-send-email-rasesh.mody@cavium.com> <677179b8-eb63-d53d-a0a5-e2c136499d3d@intel.com> In-Reply-To: <677179b8-eb63-d53d-a0a5-e2c136499d3d@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=cavium.com; x-originating-ip: [173.186.134.106] x-microsoft-exchange-diagnostics: 1; BLUPR0701MB1572; 7:yGSbxZ4aKRuEMT2lo7cXscunkfl4wzYqLybAeTpQ9hPO3FqwRiAocpiFdALXlkOJjl4RLVG2CFKHXAkiUIyFzcLRh4uQb7oOnTuzWiIqb4r6NrWAYO75nmgicFEhyRn46mnBB0+F1+AcIAIgpDJFrNGGKlvbnywuPr7WdbybU7wD5TtpT20TunCvGYolFRJ4YHMEcTnp2Hb7GQ0q8fXCxa9aOGGdbcEr+3w3qeudZkbAZWi7xdPYJu+o4gOjvLvd8Qj0B164ZqxFzSS3A4Btfro9aPdVz3eb4x7oUxZQ9gRxqhiJ8ADRuWsarDAqVM4zdlD7X41palC8T/If9uG7oA== x-ms-office365-filtering-correlation-id: 639566c6-2e32-40e5-4ca8-08d46dccb86b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254060); SRVR:BLUPR0701MB1572; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:BLUPR0701MB1572; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1572; x-forefront-prvs: 0250B840C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(377454003)(3280700002)(66066001)(122556002)(77096006)(74316002)(53546008)(3660700001)(81166006)(8676002)(2950100002)(229853002)(189998001)(53936002)(7696004)(7736002)(38730400002)(6246003)(305945005)(4326008)(107886003)(55016002)(5660300001)(25786008)(54356999)(76176999)(2906002)(99286003)(50986999)(8936002)(86362001)(33656002)(6116002)(102836003)(2900100001)(3846002)(2501003)(6436002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1572; H:BLUPR0701MB1572.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2017 07:02:19.9628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1572 Subject: Re: [dpdk-dev] [PATCH 02/21] net/qede/base: fix to set pointers to NULL after freeing 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: Sat, 18 Mar 2017 07:02:23 -0000 > From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > Sent: Thursday, March 02, 2017 5:05 AM >=20 > On 2/27/2017 7:51 AM, Rasesh Mody wrote: > > Set pointers to NULL after freeing the allocations on ecore_resc_free()= . > > > > Fixes: 26ae839d06e9 ("qede: add DCBX support") > > Fixes: ec94dbc57362 ("qede: add base driver") > > > > Signed-off-by: Rasesh Mody > > --- > > drivers/net/qede/base/ecore_dcbx.c | 2 +- > > drivers/net/qede/base/ecore_dev.c | 4 ++-- > > drivers/net/qede/base/ecore_spq.c | 2 ++ > > 3 files changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/net/qede/base/ecore_dcbx.c > > b/drivers/net/qede/base/ecore_dcbx.c > > index 7380fd8..9ce6dc4 100644 > > --- a/drivers/net/qede/base/ecore_dcbx.c > > +++ b/drivers/net/qede/base/ecore_dcbx.c > > @@ -914,7 +914,7 @@ enum _ecore_status_t > ecore_dcbx_info_alloc(struct > > ecore_hwfn *p_hwfn) void ecore_dcbx_info_free(struct ecore_hwfn > *p_hwfn, > > struct ecore_dcbx_info *p_dcbx_info) { > > - OSAL_FREE(p_hwfn->p_dev, p_hwfn->p_dcbx_info); > > + p_hwfn->p_dcbx_info =3D OSAL_NULL; >=20 >=20 > Is replacing free with "NULL assignment" intentional? It was an oversight, good catch, incorporated in v2 series, thanks. >=20 > From commit log and other updates in this patch, intention looks like > setting pointers to NULL after freeing them. >=20 > > } > > > > static void ecore_dcbx_update_protocol_data(struct protocol_dcb_data > *p_data, > > diff --git a/drivers/net/qede/base/ecore_dev.c > b/drivers/net/qede/base/ecore_dev.c > > index 0518fc7..15051b6 100644 > > --- a/drivers/net/qede/base/ecore_dev.c > > +++ b/drivers/net/qede/base/ecore_dev.c > > @@ -156,6 +156,7 @@ void ecore_resc_free(struct ecore_dev *p_dev) > > p_dev->fw_data =3D OSAL_NULL; > > > > OSAL_FREE(p_dev, p_dev->reset_stats); > > + p_dev->reset_stats =3D OSAL_NULL; >=20 > Since already a macro used for free, does it make sense to make NULL > assignment part of macro? Incorporated in v2 series.