Coverity: iwl_dbg_tlv_alloc_fragment(): Control flow issues

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):

Addresses-Coverity-ID: 1487402 ("Control flow issues")

Thanks for your attention!

Coverity-bot

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.