From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 2215314EC for ; Wed, 7 Nov 2018 21:07:57 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2018 12:07:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,476,1534834800"; d="scan'208";a="247840263" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga004.jf.intel.com with ESMTP; 07 Nov 2018 12:07:55 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by IRSMSX106.ger.corp.intel.com ([169.254.8.163]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 20:07:55 +0000 From: "Ananyev, Konstantin" To: Stephen Hemminger CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC 3/5] bpf: fix validation of eal_divmod Thread-Index: AQHUdhqraOPWuQqHjU2GpN+WDdwfO6VERO7ggAB1foCAAAME4A== Date: Wed, 7 Nov 2018 20:07:54 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580103069E14@irsmsx105.ger.corp.intel.com> References: <20181106214901.1392-1-stephen@networkplumber.org> <20181106214901.1392-4-stephen@networkplumber.org> <2601191342CEEE43887BDE71AB9772580103069BF3@irsmsx105.ger.corp.intel.com> <20181107115147.67f026e6@shemminger-XPS-13-9360> In-Reply-To: <20181107115147.67f026e6@shemminger-XPS-13-9360> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmUxNTE0OTAtZWIyOC00ZTY2LTkzYTItMzgwYzFjY2ZlNTRhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiaVIwMVl3M0dzXC9cL2k2eDZSYlZ4dUgrWUFpaWFhd2xoZzlDVnQwR0lUdnY2YkpDWitQeGFiTFZVNXowMHVsRjlaIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC 3/5] bpf: fix validation of eal_divmod 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: Wed, 07 Nov 2018 20:07:58 -0000 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Wednesday, November 7, 2018 7:52 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC 3/5] bpf: fix validation of eal_divmod >=20 > On Wed, 7 Nov 2018 12:54:54 +0000 > "Ananyev, Konstantin" wrote: >=20 > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminge= r > > > Sent: Tuesday, November 6, 2018 9:49 PM > > > To: dev@dpdk.org > > > Cc: Stephen Hemminger > > > Subject: [dpdk-dev] [RFC 3/5] bpf: fix validation of eal_divmod > > > > > > Coverity spotted self assignment in BPF eval_divmod. > > > > Yep, there is one. > > As I remember I have to add it because one of old versions > > of compiler (clang???) complained about 'variable being used uninitiali= zed'. > > > > > This looks like a bug where the incoming source register > > > should have been used instead. > > > > Nope, that's a wrong guess. > > We shouldn't do it here. > > Konstantin > > > > > > > > Coverity issue: 302850 > > > Fixes: 8021917293d0 ("bpf: add extra validation for input BPF program= ") > > > Signed-off-by: Stephen Hemminger > > > --- > > > lib/librte_bpf/bpf_validate.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/lib/librte_bpf/bpf_validate.c b/lib/librte_bpf/bpf_valid= ate.c > > > index 83983efc4e5c..b768f72c4c02 100644 > > > --- a/lib/librte_bpf/bpf_validate.c > > > +++ b/lib/librte_bpf/bpf_validate.c > > > @@ -512,7 +512,7 @@ eval_divmod(uint32_t op, struct bpf_reg_val *rd, = struct bpf_reg_val *rs, > > > if (op =3D=3D BPF_MOD) > > > rd->u.max =3D RTE_MIN(rd->u.max, rs->u.max - 1); > > > else > > > - rd->u.max =3D rd->u.max; > > > + rd->u.max =3D rs->u.max; > > > rd->u.min =3D 0; > > > } > > > > > > -- > > > 2.17.1 > > >=20 > Well it was being used unintialized,=20 I don't think so, but if you can point to me where exactly it is used uninitialized, we can discuss it further. > your trick of self assignment fooled clang It was one particular and pretty old version of clang (if my memory serves me right). With latest versions (let say 6.0) it doesn't complain, if I remove that self-assignment. gcc also doesn't see any problem here. That makes me think it was a false-positive with old version of the compiler. Konstantin=20 > but did not fool Coverity. What does the other BPF validator do?