From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 2DD3BA05D3 for ; Fri, 26 Apr 2019 14:35:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D65E81B603; Fri, 26 Apr 2019 14:35:42 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id ACD541B5F0; Fri, 26 Apr 2019 14:35:40 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 05:35:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,397,1549958400"; d="scan'208";a="153972719" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.251.92.20]) ([10.251.92.20]) by orsmga002.jf.intel.com with ESMTP; 26 Apr 2019 05:35:38 -0700 To: "Hunt, David" , dev@dpdk.org Cc: stable@dpdk.org References: <20190426084415.3979-1-david.hunt@intel.com> <109520e2-b6fc-418c-81e9-03b7821ea2ed@intel.com> <7f275a33-f5d4-d8e4-f637-4a75f5bb50f9@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 26 Apr 2019 13:35:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <7f275a33-f5d4-d8e4-f637-4a75f5bb50f9@intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v1] examples/vm_power_manager: fix overflowed return value 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" Message-ID: <20190426123537.DHMsH9UINoUiTTDI_kBYlMGSX9w5G8Y2NWpqQP46V7E@z> On 26-Apr-19 1:03 PM, Burakov, Anatoly wrote: > On 26-Apr-19 12:14 PM, Hunt, David wrote: >> Hi Anatoly, >> >> On 26/4/2019 11:29 AM, Burakov, Anatoly wrote: >>> On 26-Apr-19 9:44 AM, David Hunt wrote: >>>> Coverity complains about the return of a value that may >>>> possibly overflow because of a multiply. Limit the value >>>> so it cannot overflow. >>>> >>>> Coverity issue: 337677 >>>> Fixes: 4b1a631b8a ("examples/vm_power: add oob monitoring functions") >>>> CC: stable@dpdk.org >>>> Signed-off-by: David Hunt >>>> --- >>>>   examples/vm_power_manager/oob_monitor_x86.c | 5 ++++- >>>>   1 file changed, 4 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/examples/vm_power_manager/oob_monitor_x86.c >>>> b/examples/vm_power_manager/oob_monitor_x86.c >>>> index ebd96b205..2074eec1e 100644 >>>> --- a/examples/vm_power_manager/oob_monitor_x86.c >>>> +++ b/examples/vm_power_manager/oob_monitor_x86.c >>>> @@ -99,7 +99,10 @@ apply_policy(int core) >>>>           return -1.0; >>>>       } >>>>   -    ratio = (float)miss_diff * (float)100 / (float)hits_diff; >>>> +    ratio = (float)miss_diff / (float)hits_diff; >>>> +    if (ratio > 1.0) >>>> +        ratio = 1.0; >>>> +    ratio *= 100.0f; >>> >>> It should probably be the other way around - multiply first, then >>> clamp. Also, please use RTE_MIN. >>> >> I tried that, but coverity still sees an overflow condition. I need to >> clamp first, then multiply. Then coverity is happy. > > That's weird. This may be a bug in Coverity then. Please correct me if > i'm wrong, but floating point formats aren't precise, so by doing > multiplication on a value that doesn't exceed 1.0, you may very well end > up with a value that does exceed 100 by a tiny bit on account of > floating point approximations, rounding errors etc. > > The question is, do we want correct code, or do we want to keep Coverity > happy? :) I'll have a look at the coverity issue itself, maybe i'm > missing something here... > I think the real source of the problem is not that, and i believe there's something wrong with Coverity's analysis here. For some reason Coverity thinks that multiplying two floating point values (100f and miss_diff converted to float) will result in /integer/ overflow (lolwut?), *and* it assumes that miss_diff is negative at that point when it *can't* be, because if miss_diff was negative, we would've done an early exit on line 77. My guess is, this is the culprit: "overflow: Multiply operation overflows on operands (float)miss_diff and 100f. Example values for operands: *100f = 268435456*, (float)miss_diff = -2147483648." The "100f = 268435456" part makes me suspect that Coverity somehow thinks that "100f" is a variable name? >> >> Also, do you really want me to change to use RTE_MIN? I honestly >> prefer the code as it is. > > No strong opinion here. > >> >> >> >>>>         if (ratio < ci->branch_ratio_threshold) >>>>           power_manager_scale_core_min(core); >>>> >>> >>> >> > > -- Thanks, Anatoly