[dpdk-dev] New Coverity warnings

[dpdk-dev] New Coverity warnings

[Stephen Hemminger]

*** CID 120410:  Error handling issues  (CHECKED_RETURN)
/examples/l2fwd-keepalive/main.c: 571 in dead_core()
565     
566     static void
567     dead_core(__attribute__((unused)) void *ptr_data, const int id_core)
568     {
569     	printf("Dead core %i - restarting..\n", id_core);
570     	if (rte_eal_get_lcore_state(id_core) == FINISHED) {
>>>     CID 120410:  Error handling issues  (CHECKED_RETURN)
>>>     Calling "rte_eal_wait_lcore" without checking return value (as is done elsewhere 32 out of 40 times).  
571     		rte_eal_wait_lcore(id_core);
572     		rte_eal_remote_launch(l2fwd_launch_one_lcore, NULL, id_core);
573     	} else {
574     		printf("..false positive!\n");
575     	}
576     }

** CID 37790:  Error handling issues  (CHECKED_RETURN)
/examples/bond/main.c: 593 in cmd_stop_parsed()


________________________________________________________________________________________________________
*** CID 37790:  Error handling issues  (CHECKED_RETURN)
/examples/bond/main.c: 593 in cmd_stop_parsed()
587     					"lcore_main not running on core:%d\n",
588     					global_flag_stru_p->LcoreMainCore);
589     		rte_spinlock_unlock(&global_flag_stru_p->lock);
590     		return;
591     	}
592     	global_flag_stru_p->LcoreMainIsRunning = 0;
>>>     CID 37790:  Error handling issues  (CHECKED_RETURN)
>>>     Calling "rte_eal_wait_lcore" without checking return value (as is done elsewhere 32 out of 40 times).  
593     	rte_eal_wait_lcore(global_flag_stru_p->LcoreMainCore);
594     	cmdline_printf(cl,
595     			"lcore_main stopped on core:%d\n",
596     			global_flag_stru_p->LcoreMainCore);
597     	rte_spinlock_unlock(&global_flag_stru_p->lock);
598     }

** CID 37789:  Error handling issues  (CHECKED_RETURN)
/examples/bond/main.c: 631 in cmd_quit_parsed()


________________________________________________________________________________________________________
*** CID 37789:  Error handling issues  (CHECKED_RETURN)
/examples/bond/main.c: 631 in cmd_quit_parsed()
625     					global_flag_stru_p->LcoreMainCore);
626     		rte_spinlock_unlock(&global_flag_stru_p->lock);
627     		cmdline_quit(cl);
628     		return;
629     	}
630     	global_flag_stru_p->LcoreMainIsRunning = 0;
>>>     CID 37789:  Error handling issues  (CHECKED_RETURN)
>>>     Calling "rte_eal_wait_lcore" without checking return value (as is done elsewhere 32 out of 40 times).  
631     	rte_eal_wait_lcore(global_flag_stru_p->LcoreMainCore);
632     	cmdline_printf(cl,
633     			"lcore_main stopped on core:%d\n",
634     			global_flag_stru_p->LcoreMainCore);
635     	rte_spinlock_unlock(&global_flag_stru_p->lock);
636     	cmdline_quit(cl);

Re: [dpdk-dev] New Coverity warnings

[Mcnamara, John]

Hi,

Stephen, thanks for highlighting this.

For the last few analysis runs I have been generating some automatic emails from these summary emails and git blame. There is an example below.

I'd like to do this for all of the open defects but can't find a way to generate a similar report for existing defects. Also, assigning defects within the web app doesn't seem to email the assignee. The open source version of Coverity scan doesn't seem to have a web services interface like the commercial version (you get what you pay for) so I can't easily query it.

If anyone knows more about automating Coverity scan let me know.

But as Stephen says there are a lot of low-lying fruit that could be fixed:

    http://scan.coverity.com/projects/dpdk-data-plane-development-kit

John.


P.S. Sample email based on Coverity report:



Hi,

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: 120412
    Fixes: b4aee0fb9c6d ("examples/ip_pipeline: reconfigure thread binding dynamically")

  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: examples/ip_pipeline: reconfigure thread binding dynamically
Id:     b4aee0fb9c6d4fee771271d6c03a65dc27ba024a
Author: Piotr Azarewicz
Email:  piotrx.t.azarewicz@intel.com
Date:   Thu Oct 29 15:36:53 2015 +0100

Defect information
==================

/examples/ip_pipeline/thread_fe.c: 338 in app_pipeline_thread_cmd_push()
*** CID 120412:  Code maintainability issues  (SIZEOF_MISMATCH)
332             /* Check for available slots in the application commands array */
333             n_cmds = RTE_DIM(thread_cmds) - 1;
334             if (n_cmds > APP_MAX_CMDS - app->n_cmds)
335                     return -ENOMEM;
336     
337             /* Push thread commands into the application */
>>>     CID 120412:  Code maintainability issues  (SIZEOF_MISMATCH)
>>>     Passing argument "&app->cmds[app->n_cmds]" of type "cmdline_parse_ctx_t *" and argument "n_cmds * 8UL /* sizeof (cmdline_parse_ctx_t *) */" to function "memcpy" is suspicious. In this case, "sizeof (cmdline_parse_ctx_t *)" is equal to "sizeof (cmdline_parse_ctx_t)", but this is not a portable assumption.
338             memcpy(&app->cmds[app->n_cmds],
339                             thread_cmds,
340                     n_cmds * sizeof(cmdline_parse_ctx_t *));
341     
342             for (i = 0; i < n_cmds; i++)
34