From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <cunming.liang@intel.com> Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id D25739AA5 for <dev@dpdk.org>; Wed, 25 Feb 2015 10:52:57 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 25 Feb 2015 01:52:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,643,1418112000"; d="scan'208";a="683126677" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by fmsmga002.fm.intel.com with ESMTP; 25 Feb 2015 01:52:50 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Feb 2015 17:52:49 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.62]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.161]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 17:52:48 +0800 From: "Liang, Cunming" <cunming.liang@intel.com> To: Thomas Monjalon <thomas.monjalon@6wind.com> Thread-Topic: [dpdk-dev] [PATCH v1] afpacket: fix critical issue reported by klocwork Thread-Index: AQHQRqNwhvSBMF7XLES/6hu6NA5kfZz42iyAgACLZQCABzieEP///VIAgACWh/A= Date: Wed, 25 Feb 2015 09:52:47 +0000 Message-ID: <D0158A423229094DA7ABF71CF2FA0DA3118DED48@shsmsx102.ccr.corp.intel.com> References: <1423732089-6202-1-git-send-email-cunming.liang@intel.com> <20150220183854.GA4179@tuxdriver.com> <D0158A423229094DA7ABF71CF2FA0DA3118DE679@shsmsx102.ccr.corp.intel.com> <1514821.oaVEE2NRMm@xps13> In-Reply-To: <1514821.oaVEE2NRMm@xps13> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" <dev@dpdk.org>, John Linville <linville@redhat.com> Subject: Re: [dpdk-dev] [PATCH v1] afpacket: fix critical issue reported by klocwork X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 25 Feb 2015 09:52:58 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, February 25, 2015 4:46 PM > To: Liang, Cunming > Cc: John W. Linville; dev@dpdk.org; John Linville > Subject: Re: [dpdk-dev] [PATCH v1] afpacket: fix critical issue reported = by > klocwork >=20 > 2015-02-25 00:57, Liang, Cunming: > > From: John W. Linville [mailto:linville@tuxdriver.com] > > > On Fri, Feb 20, 2015 at 11:19:59AM +0100, Thomas Monjalon wrote: > > > > 2015-02-12 17:08, Cunming Liang: > > > > > --- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c > > > > > +++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c > > > > > @@ -439,13 +439,15 @@ rte_pmd_init_internals(const char *name, > > > > > size_t ifnamelen; > > > > > unsigned k_idx; > > > > > struct sockaddr_ll sockaddr; > > > > > - struct tpacket_req *req; > > > > > + struct tpacket_req *req =3D NULL; > > > > > > > > If *internals is set to NULL, there should be no case where req use= d > > > > and undefined. > > > > [LCM] Agree, so that's why I add '*internals =3D NULL' below as well. > > > > > > I agree -- it looks to me like req is protected by checking for > > > *internals =3D=3D NULL. I don't think this patch is necessary. > > > > [LCM] The major piece of the patch is add setting for '*internals=3DNUL= L;'. >=20 > Yes understood, but it is already initialized to NULL before calling > rte_pmd_init_internals(): > http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_af_packet/rte_eth_af_pack= et > .c#n706 [LCM] I see, it's complained by klocwork. So either adding 'internals=3DNULL' or adding some comments helps to avoid = checking again on the next scanning. How do you think ?