From: Luciano Coelho <luciano.coelho@intel•com>
To: coverity-bot <keescook@chromium•org>,
Shahar S Matityahu <shahar.s.matityahu@intel•com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor•com>,
linux-next@vger•kernel.org
Subject: Re: Coverity: iwl_dbg_tlv_alloc_fragment(): Control flow issues
Date: Mon, 25 Nov 2019 11:49:41 +0200 [thread overview]
Message-ID: <539a97a80cab6424df2fe8d2120374c5e39892ef.camel@intel.com> (raw)
In-Reply-To: <201911040937.0079956C5@keescook>
On Mon, 2019-11-04 at 09:37 -0800, coverity-bot wrote:
> Hello!
>
> This is an experimental automated report about issues detected by Coverity
> from a scan of next-20191031 as part of the linux-next weekly scan project:
> https://scan.coverity.com/projects/linux-next-weekly-scan
>
> You're getting this email because you were associated with the identified
> lines of code (noted below) that were touched by recent commits:
>
> 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow")
>
> Coverity reported the following:
>
> *** CID 1487402: Control flow issues (DEADCODE)
> /drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c: 497 in iwl_dbg_tlv_alloc_fragment()
> 491 pages * PAGE_SIZE);
> 492
> 493 pages = DIV_ROUND_UP(pages, 2);
> 494 }
> 495
> 496 if (!block)
> vvv CID 1487402: Control flow issues (DEADCODE)
> vvv Execution cannot reach this statement: "return -12;".
> 497 return -ENOMEM;
> 498
> 499 frag->physical = physical;
> 500 frag->block = block;
> 501 frag->size = pages * PAGE_SIZE;
> 502
>
> If this is a false positive, please let us know so we can mark it as
> such, or teach the Coverity rules to be smarter. If not, please make
> sure fixes get into linux-next. :) For patches fixing this, please
> include these lines (but double-check the "Fixes" first):
>
> Reported-by: coverity-bot <keescook+coverity-bot@chromium•org>
> Addresses-Coverity-ID: 1487402 ("Control flow issues")
> Fixes: 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow")
>
>
> Thanks for your attention!
Hi,
This is a good catch! We have a loop:
while (pages) {
block = dma_alloc_coherent(fwrt->dev, pages * PAGE_SIZE,
&physical,
GFP_KERNEL | __GFP_NOWARN);
if (block)
break;
IWL_WARN(fwrt, "WRT: Failed to allocate fragment size %lu\n",
pages * PAGE_SIZE);
pages = DIV_ROUND_UP(pages, 2);
}
if (!block)
return -ENOMEM;
Which seems like it will keep trying allocate smaller and smaller
blocks until it succeeds. But "pages" will never become zero (because
of the DIV_ROUND_UP), so if we can't allocate any size and pages
becomes 1, we will keep trying to allocate 1 page until it succeeds.
And in that case, as coverity reported, block will never be NULL.
I'll add a fix to this in our internal tree and it will reach the
mainline following our normal upstream process.
--
Cheers,
Luca.
prev parent reply other threads:[~2019-11-25 9:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 17:37 Coverity: iwl_dbg_tlv_alloc_fragment(): Control flow issues coverity-bot
2019-11-25 9:49 ` Luciano Coelho [this message]
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=539a97a80cab6424df2fe8d2120374c5e39892ef.camel@intel.com \
--to=luciano.coelho@intel$(echo .)com \
--cc=gustavo@embeddedor$(echo .)com \
--cc=keescook@chromium$(echo .)org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=shahar.s.matityahu@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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