rte_bitmap_free() Re: DPDK Coverity issue 426433

rte_bitmap_free() Re: DPDK Coverity issue 426433

[Boyer, Andrew]

Hello John,
While Coverity is correct that this is a useless call, that's an internal implementation detail of rte_bitmap_free() - not really something the caller should know about.

Can we annotate rte_bitmap_free() in some way to eliminate these? This is not the first PMD that's had this issue reported against it.

Thanks,
Andrew

> On Jun 20, 2024, at 7:18 AM, John McNamara <john.mcnamara@intel.com> wrote:
> 
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> Hi Andrew,
> 
> This is an automated email in relation to a new Coverity static code analysis
> issue in DPDK. Details of the issue are below.
> 
> The email has been sent to you because you have been identified as the author
> or maintainer of the code where the defect appears.
> 
> There are several possible scenarios:
> 
> * The defect identified isn't a real issue: In this case you can edit the
>  defect online and change the defect "Classification" to "False Positive" or
>  "Intentional" and change the "Action" to "Ignore". You should also update
>  the "Severity", add yourself as the "Owner" and add a comment note.
> 
> * The defect is a real issue: In this case you should submit a patch to fix
>  the issues. The patch should include the following information in addition
>  to the usual comments and signoff:
> 
>    Coverity issue: 426433
>    Fixes: 6bc7f2cf6687 ("crypto/ionic: support sessions")
> 
>  In Coverity you should update the Classification, Severity, Action (to "Fix
>  required" or "Fix Submitted"), Owner and a Comment if necessary.
> 
> * The defect wasn't introduced by you. The line where the defect occurs may
>  not be the source of the defect. If this is the case then let the actual
>  author of the defect know by forwarding this email with a note or reply to
>  the sender of this automated email: <john.mcnamara@intel.com>
> 
> You can review the defects online at:
> 
>    http://scan.coverity.com/projects/dpdk-data-plane-development-kit
> 
> If you aren't registered for the DPDK Coverity you can do so here:
> 
>    http://scan.coverity.com/users/sign_up
> 
> Git commit data and Coverity defect information below.
> 
> Commit data
> ===========
> 
> Commit: crypto/ionic: support sessions
> Id:     6bc7f2cf6687126e265d848bcb83743a68f96ad6
> Author: Andrew Boyer
> Email:  andrew.boyer@amd.com
> Date:   Fri Jun  7 14:27:37 2024 -0700
> 
> Defect information
> ==================
> 
> /drivers/crypto/ionic/ionic_crypto_main.c: 816 in iocpt_free_objs()
> *** CID 426433:  Incorrect expression  (USELESS_CALL)
> 810             for (i = 0; i < dev->crypto_dev->data->nb_queue_pairs; i++) {
> 811                     iocpt_cryptoq_free(queue_pairs[i]);
> 812                     queue_pairs[i] = NULL;
> 813             }
> 814
> 815             if (dev->sess_bm != NULL) {
>>>>    CID 426433:  Incorrect expression  (USELESS_CALL)
>>>>    Calling "rte_bitmap_free(dev->sess_bm)" is only useful for its return value, which is ignored.
> 816                     rte_bitmap_free(dev->sess_bm);
> 817                     rte_free(dev->sess_bm);
> 818                     dev->sess_bm = NULL;
> 819             }
> 820
> 821             if (dev->adminq != NULL) {
> 

Re: rte_bitmap_free() Re: DPDK Coverity issue 426433

[Stephen Hemminger]

On Thu, 20 Jun 2024 13:45:39 +0000
"Boyer, Andrew" <Andrew.Boyer@amd.com> wrote:

> Hello John,
> While Coverity is correct that this is a useless call, that's an internal implementation detail of rte_bitmap_free() - not really something the caller should know about.
> 
> Can we annotate rte_bitmap_free() in some way to eliminate these? This is not the first PMD that's had this issue reported against it.
> 
> Thanks,
> Andrew
> 


The function should have not been declared void, no caller checks return value
and all other free() type functions are void. Not sure why function even
exists to be honest.

Also, bitmap code should really be split into inline (fast path)
and non inline (slow path).