From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <anatoly.burakov@intel.com>
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" <david.hunt@intel.com>, dev@dpdk.org
Cc: stable@dpdk.org
References: <20190426084415.3979-1-david.hunt@intel.com>
<ffd31c3e-9510-f3e9-0604-576b8a14d8d9@intel.com>
<109520e2-b6fc-418c-81e9-03b7821ea2ed@intel.com>
<7f275a33-f5d4-d8e4-f637-4a75f5bb50f9@intel.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <fdd47916-63f8-5348-8d2d-9601b4db9272@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 12:35:41 -0000
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 <david.hunt@intel.com>
>>>> ---
>>>> 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
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 2DD3BA05D3
for <public@inbox.dpdk.org>; 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" <david.hunt@intel.com>, dev@dpdk.org
Cc: stable@dpdk.org
References: <20190426084415.3979-1-david.hunt@intel.com>
<ffd31c3e-9510-f3e9-0604-576b8a14d8d9@intel.com>
<109520e2-b6fc-418c-81e9-03b7821ea2ed@intel.com>
<7f275a33-f5d4-d8e4-f637-4a75f5bb50f9@intel.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <fdd47916-63f8-5348-8d2d-9601b4db9272@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <david.hunt@intel.com>
>>>> ---
>>>> 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