* [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command @ 2016-12-29 12:19 Zhang Qian 2017-01-02 9:34 ` Paolo Bonzini 0 siblings, 1 reply; 6+ messages in thread From: Zhang Qian @ 2016-12-29 12:19 UTC (permalink / raw) To: pbonzini; +Cc: qemu-devel 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> --- 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; -- ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command 2016-12-29 12:19 [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command Zhang Qian @ 2017-01-02 9:34 ` Paolo Bonzini 2017-01-03 8:12 ` Zhang Qian 0 siblings, 1 reply; 6+ messages in thread From: Paolo Bonzini @ 2017-01-02 9:34 UTC (permalink / raw) To: Zhang Qian; +Cc: qemu-devel 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; > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command 2017-01-02 9:34 ` Paolo Bonzini @ 2017-01-03 8:12 ` Zhang Qian 2017-01-03 9:38 ` Paolo Bonzini 0 siblings, 1 reply; 6+ messages in thread From: Zhang Qian @ 2017-01-03 8:12 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel 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; >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command 2017-01-03 8:12 ` Zhang Qian @ 2017-01-03 9:38 ` Paolo Bonzini 2017-01-03 9:58 ` Zhang Qian 0 siblings, 1 reply; 6+ messages in thread From: Paolo Bonzini @ 2017-01-03 9:38 UTC (permalink / raw) To: Zhang Qian; +Cc: qemu-devel On 03/01/2017 09:12, Zhang Qian wrote: > 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. Uhm, is the fix simply diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index bdd1e5f..c080888 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -2701,7 +2701,7 @@ static bool scsi_block_is_passthrough(SCSIDiskState *s, uint8_t *buf) * for the number of logical blocks specified in the length * field). For other modes, do not use scatter/gather operation. */ - if ((buf[1] & 6) != 2) { + if ((buf[1] & 6) == 2) { return false; } break; then? Thanks, Paolo ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command 2017-01-03 9:38 ` Paolo Bonzini @ 2017-01-03 9:58 ` Zhang Qian 2017-01-03 17:18 ` Paolo Bonzini 0 siblings, 1 reply; 6+ messages in thread From: Zhang Qian @ 2017-01-03 9:58 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel At 2017-01-03 17:38:49, Paolo Bonzini <pbonzini@redhat.com> wrote: > > >On 03/01/2017 09:12, Zhang Qian wrote: >> 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. > >Uhm, is the fix simply > >diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c >index bdd1e5f..c080888 100644 >--- a/hw/scsi/scsi-disk.c >+++ b/hw/scsi/scsi-disk.c >@@ -2701,7 +2701,7 @@ static bool scsi_block_is_passthrough(SCSIDiskState *s, uint8_t *buf) > * for the number of logical blocks specified in the length > * field). For other modes, do not use scatter/gather operation. > */ >- if ((buf[1] & 6) != 2) { >+ if ((buf[1] & 6) == 2) { > return false; > } > break; > >then? I verified your patch, it is ok. but why not use (buf[1] & 2) == 2 ? >Thanks, > >Paolo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command 2017-01-03 9:58 ` Zhang Qian @ 2017-01-03 17:18 ` Paolo Bonzini 0 siblings, 0 replies; 6+ messages in thread From: Paolo Bonzini @ 2017-01-03 17:18 UTC (permalink / raw) To: Zhang Qian; +Cc: qemu-devel On 03/01/2017 10:58, Zhang Qian wrote: > > At 2017-01-03 17:38:49, Paolo Bonzini <pbonzini@redhat.com> wrote: >> >> >>On 03/01/2017 09:12, Zhang Qian wrote: >>> 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. >> >>Uhm, is the fix simply >> >>diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c >>index bdd1e5f..c080888 100644 >>--- a/hw/scsi/scsi-disk.c >>+++ b/hw/scsi/scsi-disk.c >>@@ -2701,7 +2701,7 @@ static bool scsi_block_is_passthrough(SCSIDiskState *s, uint8_t *buf) >> * for the number of logical blocks specified in the length >> * field). For other modes, do not use scatter/gather operation. >> */ >>- if ((buf[1] & 6) != 2) { >>+ if ((buf[1] & 6) == 2) { >> return false; >> } >> break; >> >>then? > I verified your patch, it is ok. > > but why not use (buf[1] & 2) == 2 ? Isn't BYTCHK bits 1 and 2? Paolo ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-03 17:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-29 12:19 [Qemu-devel] [PATCH] scsi-disk: fix crash on VERIFY command Zhang Qian 2017-01-02 9:34 ` Paolo Bonzini 2017-01-03 8:12 ` Zhang Qian 2017-01-03 9:38 ` Paolo Bonzini 2017-01-03 9:58 ` Zhang Qian 2017-01-03 17:18 ` Paolo Bonzini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).