Hello Joanna, Varun,
Regarding the idea of looping in Coverity Scan Online in the patch submission process, that is not possible because this free service from Synopsys only allows for a dozen of analyses to be requested per week per open-source project. If we were to request analyses for every patch submission, we would hit the limit very quickly. That is the reason why this is setup to run on the integration branch once per work week day at the moment.
I appreciate this is not ideal (as pointed out by both of you) as we get defects reports after patches have been merged but I can't see another way out of this.
Regards, Sandrine
On 7/27/20 9:08 AM, Joanna Farley via TF-A wrote:
Hi Varun,
At this time not that I know of which is why we have the solution we have. I'm sure with enough investment of effort something can be done. If we were going to do that though I would personally prefer investigating integrating this tighter into the patch review tooling and report there before patch submitting but there too lies challenges interfacing to the online Coverity server offered as a free service to opensource projects.
Cheers
Joanna
On 22/07/2020, 18:09, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces@lists.trustedfirmware.org on behalf of tf-a@lists.trustedfirmware.org> wrote:
Hi, Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? -Varun -----Original Message----- From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A Sent: Wednesday, July 22, 2020 8:17 AM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware External email: Use caution opening links or attachments Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360934: Integer handling issues (BAD_SHIFT) >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() ________________________________________________________________________________________________________ *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() 185 return; 186 } 187 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); 189 190 return_values.rate[0] = (uint32_t)rate; >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); 192 193 scmi_write_response(msg, &return_values, sizeof(return_values)); 194 } 195 196 static void scmi_clock_rate_set(struct scmi_msg *msg) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yp5YIaEOLnCdbFI-2FIc4JLP8-2FUmbB2NyPEcjqFJPhqYnGCbuJCc-2BtvVqmFI370Sr9nyYSB6KjGZP4HisQwqHQINdE71r_rJIKl4NImC2S1pVD9xH-2BTiYorMVvk9q4XtI1ZLWqo3MIdcWEDsl925ZJ5drgtRsWg1UkhD5eoQ-2BcxZrh78eTc3x513Kh0jS-2FZj4rKEKzYP2G9hsXPk5x-2BD7rHveJc9QHnPMIOaq-2Bm9KkiUhPY8fu-2FmPFWBVxjhqwvg5YW9UXHU09NFcoMX9VaCXSDdvrvc3I-2FV3Njqym7jy3aPI7z3JfB87NCFxLyTa7oktyiYPv9HxGyw8mJt7-2BXpSAv6VTJ-2Bh1 -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Sandrine, Joanna,
Thanks for the information. I think we agree that the scans during change submission are not possible. We can live with that limitation for the moment.
My concern was about the process for tracking the failure and creating the actual fix. Is there any way to create issues/tickets automatically for tracking? This way we don’t have to worry about one of these emails getting lost.
-Varun
-----Original Message----- From: Sandrine Bailleux sandrine.bailleux@arm.com Sent: Monday, July 27, 2020 2:49 AM To: Joanna Farley Joanna.Farley@arm.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware
External email: Use caution opening links or attachments
Hello Joanna, Varun,
Regarding the idea of looping in Coverity Scan Online in the patch submission process, that is not possible because this free service from Synopsys only allows for a dozen of analyses to be requested per week per open-source project. If we were to request analyses for every patch submission, we would hit the limit very quickly. That is the reason why this is setup to run on the integration branch once per work week day at the moment.
I appreciate this is not ideal (as pointed out by both of you) as we get defects reports after patches have been merged but I can't see another way out of this.
Regards, Sandrine
On 7/27/20 9:08 AM, Joanna Farley via TF-A wrote:
Hi Varun,
At this time not that I know of which is why we have the solution we have. I'm sure with enough investment of effort something can be done. If we were going to do that though I would personally prefer investigating integrating this tighter into the patch review tooling and report there before patch submitting but there too lies challenges interfacing to the online Coverity server offered as a free service to opensource projects.
Cheers
Joanna
On 22/07/2020, 18:09, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces@lists.trustedfirmware.org on behalf of tf-a@lists.trustedfirmware.org> wrote:
Hi, Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? -Varun -----Original Message----- From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A Sent: Wednesday, July 22, 2020 8:17 AM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] New Defects reported by Coverity Scan forARM-software/arm-trusted-firmware
External email: Use caution opening links or attachments Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 inwrite_rate_desc_array_in_buffer()
________________________________________________________________________________________________________ *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 inwrite_rate_desc_array_in_buffer()
________________________________________________________________________________________________________ *** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360934: Integer handling issues (BAD_SHIFT) >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() ________________________________________________________________________________________________________ *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() 185 return; 186 } 187 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); 189 190 return_values.rate[0] = (uint32_t)rate; >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); 192 193 scmi_write_response(msg, &return_values, sizeof(return_values)); 194 } 195 196 static void scmi_clock_rate_set(struct scmi_msg *msg) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit,https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy 7my0P0qcxCbhZ31OYv50yp5YIaEOLnCdbFI-2FIc4JLP8-2FUmbB2NyPEcjqFJPhqYnGCb uJCc-2BtvVqmFI370Sr9nyYSB6KjGZP4HisQwqHQINdE71r_rJIKl4NImC2S1pVD9xH-2B TiYorMVvk9q4XtI1ZLWqo3MIdcWEDsl925ZJ5drgtRsWg1UkhD5eoQ-2BcxZrh78eTc3x5 13Kh0jS-2FZj4rKEKzYP2G9hsXPk5x-2BD7rHveJc9QHnPMIOaq-2Bm9KkiUhPY8fu-2Fm PFWBVxjhqwvg5YW9UXHU09NFcoMX9VaCXSDdvrvc3I-2FV3Njqym7jy3aPI7z3JfB87NCF xLyTa7oktyiYPv9HxGyw8mJt7-2BXpSAv6VTJ-2Bh1
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Varun,
On 7/27/20 6:59 PM, Varun Wadekar wrote:
Hi Sandrine, Joanna,
Thanks for the information. I think we agree that the scans during change submission are not possible. We can live with that limitation for the moment.
My concern was about the process for tracking the failure and creating the actual fix. Is there any way to create issues/tickets automatically for tracking? This way we don’t have to worry about one of these emails getting lost.
I'd guess yes. It seems possible to interact with Phabricator through emails/command line, see https://secure.phabricator.com/applications/mailcommands/PhabricatorManiphes...
Regards, Sandrine
tf-a@lists.trustedfirmware.org
-
Sandrine Bailleux -
Varun Wadekar