From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 87A4F1B601; Fri, 26 Apr 2019 15:50:27 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 06:50:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,397,1549958400"; d="scan'208";a="294775824" Received: from dhunt5-mobl2.ger.corp.intel.com (HELO [10.237.210.15]) ([10.237.210.15]) by orsmga004.jf.intel.com with ESMTP; 26 Apr 2019 06:50:24 -0700 To: "Burakov, Anatoly" , dev@dpdk.org Cc: stable@dpdk.org References: <20190426084415.3979-1-david.hunt@intel.com> From: "Hunt, David" Message-ID: <25d6e6b5-204d-d902-f61c-e8eb565e822b@intel.com> Date: Fri, 26 Apr 2019 14:50:23 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: , X-List-Received-Date: Fri, 26 Apr 2019 13:50:28 -0000 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. > >>         if (ratio < ci->branch_ratio_threshold) >>           power_manager_scale_core_min(core); >> Anatoly and myself have spendt some time analysing the coverity issue just now, and we have come to the conclusion that it's a false positive. We also think it may be an issue with coverity, so for the moment I'll mark the coverity issue as a false positive. 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 EC6D8A05D3 for ; Fri, 26 Apr 2019 15:50:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 984441B676; Fri, 26 Apr 2019 15:50:29 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 87A4F1B601; Fri, 26 Apr 2019 15:50:27 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 06:50:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,397,1549958400"; d="scan'208";a="294775824" Received: from dhunt5-mobl2.ger.corp.intel.com (HELO [10.237.210.15]) ([10.237.210.15]) by orsmga004.jf.intel.com with ESMTP; 26 Apr 2019 06:50:24 -0700 To: "Burakov, Anatoly" , dev@dpdk.org Cc: stable@dpdk.org References: <20190426084415.3979-1-david.hunt@intel.com> From: "Hunt, David" Message-ID: <25d6e6b5-204d-d902-f61c-e8eb565e822b@intel.com> Date: Fri, 26 Apr 2019 14:50:23 +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: Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US 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: <20190426135023.nopuW1BdfQA3zvVbtLKZmWJrxumv3nWqxH6mEuixOGI@z> 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. > >>         if (ratio < ci->branch_ratio_threshold) >>           power_manager_scale_core_min(core); >> Anatoly and myself have spendt some time analysing the coverity issue just now, and we have come to the conclusion that it's a false positive. We also think it may be an issue with coverity, so for the moment I'll mark the coverity issue as a false positive.