From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id CBBEC2862 for ; Thu, 8 Nov 2018 00:04:57 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2018 15:04:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,477,1534834800"; d="scan'208";a="98479091" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga003.jf.intel.com with ESMTP; 07 Nov 2018 15:04:55 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by IRSMSX152.ger.corp.intel.com ([169.254.6.64]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 23:04: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+WDdwfO6VERO7ggAB1foCAAAME4IAAMhKg Date: Wed, 7 Nov 2018 23:04:54 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580103069E91@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> 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.182] 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 23:04:58 -0000 > > > > > > > > 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 uninitia= lized'. > > > > > > > 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 progr= am") > > > > 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_val= idate.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 > > > > > > > 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. >=20 > > your trick of self assignment fooled clang >=20 > 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 As a another thought - it wouldn't take much effort to=20 send a patch with NOP self-assignment removed. If it will pass our build-harness test, then it is probably ok to integrate. Konstantin >=20 > > but did not fool Coverity. What does the other BPF validator do?