qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command


From: Zhang Qian
Subject: Re: [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command
Date: Tue, 3 Jan 2017 16:12:50 +0800 (GMT+08:00)

At 2017-01-02 17:34:00, Paolo Bonzini <address@hidden> wrote:
>
>
>On 29/12/2016 13:19, Zhang Qian wrote:
>> From c2f1631132821d61e1942a8723ba596f91d3e672 Mon Sep 17 00:00:00 2001
>> From: Zhang Qian <address@hidden>
>> Date: Thu, 29 Dec 2016 20:00:01 +0800
>> Subject: [PATCH] scsi-disk: fix crash on VERIFY command Commit 166dbda
>>  "scsi-disk: fix VERIFY for scsi-block" add a process of VERIFY in
>>  scsi_block_dma_command. But, the cmd.mode of req is SCSI_XFER_NONE, the req
>>  is handled as a read operation. A verify command is not an actual read (we 
>> do
>>  not implement compare mode) and thus does not have an AIOCB attached. so, it
>>  will be crash in scsi_dma_complete. Commit ef8489d "scsi: avoid assertion
>>  failure on VERIFY command" is added to process verify command, so we treat
>>  verify command as a write operation.
>> Signed-off-by: Zhang Qian <address@hidden>
>
>I am not sure what the issue is, and your commit message doesn't explain
>it.  There are a few unclear aspects:
>
>1) the mode is set in scsi_cmd_xfer_mode.  For VERIFY, it is only
>SCSI_XFER_NONE if the transferred data is empty, otherwise it is
>SCSI_XFER_TO_DEV.  For BYTCHK=0x01, scsi_req_xfer sets cmd->xfer
>correctly to number-of-blocks * block-size.
>
yes, you are right. 
The scenarios of problem is a scsi-disk object receives VERIFY command with 
BYTCHK bit being zero,
scsi_block_is_passthrough returns false and finally scsi-block uses 
scsi_disk_dma_command for 
VERIFY.  So the mode is set to SCSI_XFER_NONE. 
In scsi_req_continue,  scsi_read_data function is called.


>2) Your message does not say if you're using scsi-block or
>scsi-disk/scsi-hd. Only scsi-block uses scsi_disk_dma_command for
>VERIFY, and it does have an AIOCB (created by scsi_block_dma_writev).
>If you were using virtio-scsi, then a wrong request from the guest might
>have BYTCHK=0x01 and SCSI_XFER_NONE (see virtio_scsi_parse_cdb).
>However, this does not affect whether the request has an AIOCB attached.
>
>
scsi_block_dma_writev is not called, because scsi_write_data is not called.qemu 
print error message :
qemu-2.8.0: hw/scsi/scsi-disk.c:290: scsi_dma_complete: Assertion `r->req.aiocb 
!= ((void *)0)' failed.


I use a scsi-block device. In guest os, I just executed a command “sg_verify 
/dev/sda”.


so, the current scene is not what you want.


>Please explain the issue better and, if it is for scsi-disk or scsi-hd, 
>>please provide a testcase in tests/virtio-scsi-tests.c. > >Thanks, > >Paolo > 
>>> --- >> 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 
>bdd1e5f..ab05bf9 100644 >> --- a/hw/scsi/scsi-disk.c >> +++ 
>b/hw/scsi/scsi-disk.c >> @@ -2170,6 +2170,10 @@ static int32_t 
>scsi_disk_dma_command(SCSIRequest *req, uint8_t *buf) >> if 
>(!check_lba_range(s, r->req.cmd.lba, len)) { >> goto illegal_lba; >> } >> + if 
>(command == VERIFY_10 || command == VERIFY_12 || >> + command == VERIFY_16) { 
>>> + r->req.cmd.mode = SCSI_XFER_TO_DEV; >> + } >> r->sector = r->req.cmd.lba 
>* (s->qdev.blocksize / 512); >> r->sector_count = len * (s->qdev.blocksize / 
>512); >> break; >>




reply via email to

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