* [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).