DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Stephen Hemminger <stephen@networkplumber.org>, <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/4] net/failsafe: avoid rte_memcpy if rte_realloc fails
Date: Wed, 7 Nov 2018 09:30:13 +0300	[thread overview]
Message-ID: <5d2c4750-b418-c4fe-4e20-d7cc7ca4efe7@solarflare.com> (raw)
In-Reply-To: <20181106193005.5383-2-stephen@networkplumber.org>

On 11/6/18 10:30 PM, Stephen Hemminger wrote:
> There is a potential issue seen by static tools if number of multicast
> addresses is zero, and rte_realloc of zero size fails (ie returns NULL).
> This won't happen in real world for a couple of reasons: Azure doesn't
> support multicast (ie this is dead code);

Is it guaranteed that Azure is the only user of the code?
Sorry, it does not sound like an argument at all.

> and rte_realloc of zero size
> will never fail, but safe to just always return -ENOMEM of realloc fails.

It is false statement. If ptr is NULL, rte_malloc() is used which explicitly
returns NULL if size is 0.

> Coverity issue: 323487

It is 100% false alarm from Coverity. rte_memcpy() does nothing
if size is 0 and it is zero if number of addresses is zero.
If we really want to cope with it (I'm not sure), just do rte_memcpy()
in else branch. And it should explained in the comment that it is
required to address false issue from static analysis tool only.

Other option is to add check for dummy set (zero number of addresses
when it is already zero, but it is extra lines of code and extra logic which
is not actually required here. So, more harm from my point of view.

> Fixes: 901efc0da925 ("net/failsafe: support multicast address list set")
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>   drivers/net/failsafe/failsafe_ops.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/failsafe/failsafe_ops.c b/drivers/net/failsafe/failsafe_ops.c
> index 7f8bcd4c69f4..a20953a662e1 100644
> --- a/drivers/net/failsafe/failsafe_ops.c
> +++ b/drivers/net/failsafe/failsafe_ops.c
> @@ -1155,7 +1155,7 @@ fs_set_mc_addr_list(struct rte_eth_dev *dev,
>   
>   	mcast_addrs = rte_realloc(PRIV(dev)->mcast_addrs,
>   		nb_mc_addr * sizeof(PRIV(dev)->mcast_addrs[0]), 0);
> -	if (mcast_addrs == NULL && nb_mc_addr > 0) {
> +	if (mcast_addrs == NULL) {
>   		ret = -ENOMEM;
>   		goto rollback;
>   	}

  reply	other threads:[~2018-11-07  6:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06 19:30 [dpdk-dev] [PATCH 0/4] Coverity issue fixes Stephen Hemminger
2018-11-06 19:30 ` [dpdk-dev] [PATCH 1/4] net/failsafe: avoid rte_memcpy if rte_realloc fails Stephen Hemminger
2018-11-07  6:30   ` Andrew Rybchenko [this message]
2018-11-07 18:15     ` Stephen Hemminger
2018-11-08  6:20       ` Andrew Rybchenko
2018-11-06 19:30 ` [dpdk-dev] [PATCH 2/4] bus/vmbus: fix directory handle leak on error Stephen Hemminger
2018-11-06 19:30 ` [dpdk-dev] [PATCH 3/4] net/tap: fix file descriptor " Stephen Hemminger
2018-11-07 10:02   ` Wiles, Keith
2018-11-06 19:30 ` [dpdk-dev] [PATCH 4/4] net/tap: fix warning about comparison of fd Stephen Hemminger
2018-11-07 10:03   ` Wiles, Keith
2018-11-14  1:00 ` [dpdk-dev] [PATCH 0/4] Coverity issue fixes Thomas Monjalon

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=5d2c4750-b418-c4fe-4e20-d7cc7ca4efe7@solarflare.com \
    --to=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    /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).