DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wei Hu (Xavier)" <xavier.huwei@huawei.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: <dev@dpdk.org>, <xavier.huwei@huawei.com>
Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix passing negative parameter to strerror
Date: Fri, 5 Jun 2020 10:57:38 +0800	[thread overview]
Message-ID: <66ad25cf-1cdb-c470-ae8a-260929ff6fab@huawei.com> (raw)
In-Reply-To: <cda578a0-1c2c-30ee-61a8-61019d70ed6f@intel.com>



On 2020/6/5 0:30, Ferruh Yigit wrote:
> On 6/4/2020 7:22 AM, Wei Hu (Xavier) wrote:
>> Currently, there are coverity defect warnings as blow:
>> Coverity issue:
>>    In nic_stats_clear function:
>>      CID 290021 (#1 of 1): Argument cannot be negative (NEGATIVE_RETURNS)
>>      5. negative_returns: ret is passed to a parameter that cannot be
>>         negative.
>>
>>      CID 289974 (#1 of 1): Argument cannot be negative (NEGATIVE_RETURNS)
>>      6. negative_returns: ret is passed to a parameter that cannot be
>>         negative.
>>
>>    In nic_xstats_clear function:
>>      CID 289985 (#1 of 1): Argument cannot be negative (NEGATIVE_RETURNS)
>>      5. negative_returns: ret is passed to a parameter that cannot be
>>         negative.
>>
>>      CID 289850 (#1 of 1): Argument cannot be negative (NEGATIVE_RETURNS)
>>      6. negative_returns: ret is passed to a parameter that cannot be
>>         negative.
> I guess these coverity IDs are from the internal coverity, because I can't find
> them in the public coverity.
> If it is internal, not sure about the benefit of documenting them in the commit
> log, since no one except huawei can access them. What do you think to remove all
> above reference?
Yes, these are internal covertiy defects information. Maybe we can remove
internal coverity CID xxxx and reserve the description of the defect in the
commit log.

By the way,  when we access the "View defects" on the page of the public 
coverity
https://scan.coverity.com/projects/dpdk-data-plane-development-kit?tab=overview 

, The browser prompts HTTP ERROR 403.
>> This patch fixes them by passing '-ret' to the function strerror() when ret
>> is negative.
>>
>> Fixes: af75078fece3 ("first public release")
>> Fixes: 9eb974221f44 ("app/testpmd: fix statistics after reset")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
>> ---
>>   app/test-pmd/config.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
>> index 5381207..356d0d2 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -244,14 +244,14 @@ nic_stats_clear(portid_t port_id)
>>   	ret = rte_eth_stats_reset(port_id);
>>   	if (ret != 0) {
>>   		printf("%s: Error: failed to reset stats (port %u): %s",
>> -		       __func__, port_id, strerror(ret));
>> +		       __func__, port_id, strerror(-ret));
>>   		return;
>>   	}
>>   
>>   	ret = rte_eth_stats_get(port_id, &ports[port_id].stats);
>>   	if (ret != 0) {
>>   		printf("%s: Error: failed to get stats (port %u): %s",
>> -		       __func__, port_id, strerror(ret));
>> +		       __func__, port_id, strerror(-ret));
> Although in practice this may be the case, the 'rte_eth_stats_get()' function
> documentation doesn't guarantee that return value will be negative, it says:
>
> "
>   * @return
>   *   Zero if successful. Non-zero otherwise
> "
>
> To be accurate, what do you think to adding a negative check for 'ret' before
> doing '-ret'?
OK, we will add a negative check in V2.

Thanks, Xavier


  reply	other threads:[~2020-06-05  2:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04  6:22 Wei Hu (Xavier)
2020-06-04  8:45 ` Phil Yang
2020-06-04 10:51   ` Kevin Traynor
2020-06-04 16:30 ` Ferruh Yigit
2020-06-05  2:57   ` Wei Hu (Xavier) [this message]
2020-06-05  9:25     ` Ferruh Yigit
2020-06-06  3:47       ` Wei Hu (Xavier)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66ad25cf-1cdb-c470-ae8a-260929ff6fab@huawei.com \
    --to=xavier.huwei@huawei.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).