While investigating link-time-optimization, the compiler flagged this
case of not handling the error return from scsi_cdb_length(). Handle
this error case with a trace report.

Signed-off-by: Bruce Rogers <brogers@suse.com>
---
 hw/scsi/scsi-disk.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index e7e865ab3b..8fbf7512e5 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2520,6 +2520,10 @@ static void scsi_disk_new_request_dump(uint32_t lun, uint32_t tag, uint8_t *buf)
     int len = scsi_cdb_length(buf);
     char *line_buffer, *p;
 
+    if (len < 0) {
+        trace_scsi_disk_new_request(lun, tag, "bad cdb length");
+        return;
+    }
     line_buffer = g_malloc(len * 5 + 1);
 
     for (i = 0, p = line_buffer; i < len; i++) {
-- 
2.21.0

On 4/30/19 9:19 AM, Bruce Rogers wrote:
> While investigating link-time-optimization, the compiler flagged this
> case of not handling the error return from scsi_cdb_length(). Handle
> this error case with a trace report.
> 
> Signed-off-by: Bruce Rogers <brogers@suse.com>
> ---
>  hw/scsi/scsi-disk.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index e7e865ab3b..8fbf7512e5 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -2520,6 +2520,10 @@ static void scsi_disk_new_request_dump(uint32_t lun, uint32_t tag, uint8_t *buf)
>      int len = scsi_cdb_length(buf);
>      char *line_buffer, *p;
>  
> +    if (len < 0) {
> +        trace_scsi_disk_new_request(lun, tag, "bad cdb length");

This is going to print:

"Command: lun=%d tag=0x%x data=bad cdb length"

which is maybe not the best. I'd rather print something more direct, but
it's probably better than actually rolling forward with len = -1.

Then again, this should literally never happen, because scsi_req_new is
parsing the cdb object and already rejecting such cases.

Can you satisfy the compiler by asserting that it is greater than zero?
It ought to be provably true.

--js

> +        return;
> +    }
>      line_buffer = g_malloc(len * 5 + 1);
>  
>      for (i = 0, p = line_buffer; i < len; i++) {
> 

>>> On 4/30/2019 at 2:40 PM, John Snow <jsnow@redhat.com> wrote:

> 
> On 4/30/19 9:19 AM, Bruce Rogers wrote:
>> While investigating link-time-optimization, the compiler flagged this
>> case of not handling the error return from scsi_cdb_length(). Handle
>> this error case with a trace report.
>> 
>> Signed-off-by: Bruce Rogers <brogers@suse.com>
>> ---
>>  hw/scsi/scsi-disk.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
>> index e7e865ab3b..8fbf7512e5 100644
>> --- a/hw/scsi/scsi-disk.c
>> +++ b/hw/scsi/scsi-disk.c
>> @@ -2520,6 +2520,10 @@ static void scsi_disk_new_request_dump(uint32_t lun, 
> uint32_t tag, uint8_t *buf)
>>      int len = scsi_cdb_length(buf);
>>      char *line_buffer, *p;
>>  
>> +    if (len < 0) {
>> +        trace_scsi_disk_new_request(lun, tag, "bad cdb length");
> 
> This is going to print:
> 
> "Command: lun=%d tag=0x%x data=bad cdb length"
> 
> which is maybe not the best. I'd rather print something more direct, but
> it's probably better than actually rolling forward with len = -1.
> 
> Then again, this should literally never happen, because scsi_req_new is
> parsing the cdb object and already rejecting such cases.
> 

Indeed, that is true.


> Can you satisfy the compiler by asserting that it is greater than zero?
> It ought to be provably true.

Yes, that seems to work and is probably the way to go. I'll send a patch
with that approach then. Thanks for the review.

> 
> --js
> 
>> +        return;
>> +    }
>>      line_buffer = g_malloc(len * 5 + 1);
>>  
>>      for (i = 0, p = line_buffer; i < len; i++) {
>> 

Bruce