qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] iscsi: Don't access non-existent scsi_lba_status_descriptor


From: Kevin Wolf
Subject: Re: [PATCH] iscsi: Don't access non-existent scsi_lba_status_descriptor
Date: Fri, 24 Jan 2020 14:45:04 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

Am 23.01.2020 um 21:37 hat John Snow geschrieben:
> On 1/23/20 12:05 PM, Kevin Wolf wrote:
> > In iscsi_co_block_status(), we may have received num_descriptors == 0
> > from the iscsi server. Therefore, we can't unconditionally access
> > lbas->descriptors[0]. Add the missing check.
> > 
> > Signed-off-by: Kevin Wolf <address@hidden>
> > ---
> >  block/iscsi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/block/iscsi.c b/block/iscsi.c
> > index cbd57294ab..c8feaa2f0e 100644
> > --- a/block/iscsi.c
> > +++ b/block/iscsi.c
> > @@ -753,7 +753,7 @@ retry:
> >      }
> >  
> >      lbas = scsi_datain_unmarshall(iTask.task);
> > -    if (lbas == NULL) {
> > +    if (lbas == NULL || lbas->num_descriptors == 0) {
> >          ret = -EIO;
> >          goto out_unlock;
> >      }
> > 
> 
> Naive question: Does the specification allow for such a response? Is
> this inherently an error?

Even if iscsi allowed it, it would be a useless response, because it
means that you didn't get the block status of any block.

bdrv_co_block_status() may only return *pnum == 0 at EOF, so I don't
think we have any other option than returning an error. (We could retry,
but if a target returns a useless response once, why should we trust it
do behave better the second time?)

> Anyway, this is better than accessing junk memory, so:
> 
> Reviewed-by: John Snow <address@hidden>

Thanks!

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]