| Message ID | ABkAAQD4AB3QlUFH9YYGDar2.1.1483013998163.Hmail.zhangqian@sangfor.com.cn |
|---|---|
| State | New |
| Headers | show |
On 29/12/2016 13:19, Zhang Qian wrote: > From c2f1631132821d61e1942a8723ba596f91d3e672 Mon Sep 17 00:00:00 2001 > From: Zhang Qian <zhangqian@sangfor.com.cn> > 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 <zhangqian@sangfor.com.cn> 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. 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. 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; >
At 2017-01-02 17:34:00, Paolo Bonzini <pbonzini@redhat.com> wrote: > > >On 29/12/2016 13:19, Zhang Qian wrote: >> From c2f1631132821d61e1942a8723ba596f91d3e672 Mon Sep 17 00:00:00 2001 >> From: Zhang Qian <zhangqian@sangfor.com.cn> >> 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 <zhangqian@sangfor.com.cn> > >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; >>
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;