2021-08-21 20:33:20 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-05 15:29:12 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-09-05 15:29:12 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-28 11:35:41 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
2024-10-01 15:35:57 -04:00
|
|
|
|
2015-05-08 10:11:12 +02:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-06 14:36:13 +08:00
|
|
|
|
tcm_vhost: Multi-queue support
This adds virtio-scsi multi-queue support to tcm_vhost. In order to use
multi-queue, guest side multi-queue support is need. It can
be found here:
https://lkml.org/lkml/2012/12/18/166
Currently, only one thread is created by vhost core code for each
vhost_scsi instance. Even if there are multi-queues, all the handling of
guest kick (vhost_scsi_handle_kick) are processed in one thread. This is
not optimal. Luckily, most of the work is offloaded to the tcm_vhost
workqueue.
Some initial perf numbers:
1 queue, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 127K/127k IOPS
4 queues, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 181K/181k IOPS
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2013-02-06 13:20:59 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-08 13:29:55 -06:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
2019-05-17 00:29:49 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-27 13:13:12 -08:00
|
|
|
|
|
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
2021-02-27 10:59:58 -06:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
2014-02-22 18:08:24 -08:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
2015-01-27 13:13:12 -08:00
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-02 03:50:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-23 18:01:34 +02:00
|
|
|
|
2013-03-27 17:23:41 -07:00
|
|
|
|
2014-02-22 18:22:31 -08:00
|
|
|
|
2015-09-09 22:24:56 +03:00
|
|
|
|
2013-03-27 17:23:41 -07:00
|
|
|
|
|
|
|
|
|
tcm_vhost: Multi-queue support
This adds virtio-scsi multi-queue support to tcm_vhost. In order to use
multi-queue, guest side multi-queue support is need. It can
be found here:
https://lkml.org/lkml/2012/12/18/166
Currently, only one thread is created by vhost core code for each
vhost_scsi instance. Even if there are multi-queues, all the handling of
guest kick (vhost_scsi_handle_kick) are processed in one thread. This is
not optimal. Luckily, most of the work is offloaded to the tcm_vhost
workqueue.
Some initial perf numbers:
1 queue, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 127K/127k IOPS
4 queues, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 181K/181k IOPS
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2013-02-06 13:20:59 +08:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
|
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
2013-04-28 15:38:52 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
2013-04-28 15:38:52 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-20 09:50:59 -06:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:24 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
2013-06-06 02:20:41 -07:00
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-17 22:54:31 +03:00
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-06 02:20:41 -07:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:19 -05:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-15 19:47:00 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
2024-03-15 19:47:00 -05:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-20 09:50:59 -06:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2014-03-22 14:55:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-23 18:01:34 +02:00
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-06 02:20:41 -07:00
|
|
|
|
|
|
|
|
|
2015-04-27 13:52:36 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-31 21:27:57 +02:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-05 15:20:27 +03:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-23 18:01:34 +02:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
2024-03-15 19:46:59 -05:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2017-05-12 09:42:56 +09:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-12 09:42:56 +09:00
|
|
|
|
2024-03-15 19:46:59 -05:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-15 19:46:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
|
|
|
|
|
2013-01-06 14:36:13 +08:00
|
|
|
|
2017-11-09 09:00:21 +09:00
|
|
|
|
2013-01-06 14:36:13 +08:00
|
|
|
|
|
|
|
|
|
2015-01-27 13:13:12 -08:00
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
2017-11-09 09:00:21 +09:00
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-27 13:13:12 -08:00
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
2015-01-27 13:13:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
tcm_vhost: Multi-queue support
This adds virtio-scsi multi-queue support to tcm_vhost. In order to use
multi-queue, guest side multi-queue support is need. It can
be found here:
https://lkml.org/lkml/2012/12/18/166
Currently, only one thread is created by vhost core code for each
vhost_scsi instance. Even if there are multi-queues, all the handling of
guest kick (vhost_scsi_handle_kick) are processed in one thread. This is
not optimal. Luckily, most of the work is offloaded to the tcm_vhost
workqueue.
Some initial perf numbers:
1 queue, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 127K/127k IOPS
4 queues, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 181K/181k IOPS
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2013-02-06 13:20:59 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2014-02-22 18:22:31 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2014-02-22 18:08:24 -08:00
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-22 10:33:08 +08:00
|
|
|
|
2013-09-23 11:42:28 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-09-23 11:42:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
2014-02-22 18:08:24 -08:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
2017-05-20 13:48:44 +02:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
2014-02-22 18:08:24 -08:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
2013-06-07 17:47:46 -07:00
|
|
|
|
2014-02-22 18:22:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2014-02-22 18:22:31 -08:00
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-28 13:10:51 -08:00
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
2013-01-22 11:20:27 +08:00
|
|
|
|
2022-06-09 10:28:36 -04:00
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
2013-01-22 11:20:27 +08:00
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-03-29 08:52:15 -06:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:08 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:59 -05:00
|
|
|
|
|
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
2017-09-24 18:36:44 -04:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
2014-02-22 18:34:08 -08:00
|
|
|
|
2017-09-24 22:07:59 -04:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
2017-09-24 18:36:44 -04:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
2023-07-09 15:28:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:59 -05:00
|
|
|
|
|
|
|
|
|
2023-07-09 15:28:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-28 00:15:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 18:34:43 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-21 10:42:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-27 10:59:58 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
2021-02-27 10:59:58 -06:00
|
|
|
|
2014-02-22 18:22:31 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2014-02-22 18:22:31 -08:00
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
|
|
|
|
|
2014-02-22 18:22:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-04-14 13:26:44 +02:00
|
|
|
|
scsi: target: vhost-scsi: Convert to new submission API
target_submit_cmd_map_sgls() is being removed, so convert vhost-scsi to the
new submission API. This has it use target_init_cmd(),
target_submit_prep(), target_submit() because we need to have LIO core map
sgls which is now done in target_submit_prep(), and in the next patches we
will do the target_submit step from the LIO workqueue.
Note: vhost-scsi never calls target_stop_session() so
target_submit_cmd_map_sgls() never failed (in the new API target_init_cmd()
handles target_stop_session() being called when cmds are being
submitted). If it were to have used target_stop_session() and got an error,
we would have hit a refcount bug like xen and usb, because it does:
if (rc < 0) {
transport_send_check_condition_and_sense(se_cmd,
TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, 0);
transport_generic_free_cmd(se_cmd, 0);
}
transport_send_check_condition_and_sense() calls queue_status which does
transport_generic_free_cmd(), and then we do an extra
transport_generic_free_cmd() call above which would have dropped the
refcount to -1 and the refcount code would spit out errors.
Link: https://lore.kernel.org/r/20210227170006.5077-12-michael.christie@oracle.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-02-27 10:59:52 -06:00
|
|
|
|
2013-05-06 16:38:29 +08:00
|
|
|
|
2014-12-21 10:42:08 -08:00
|
|
|
|
scsi: target: vhost-scsi: Convert to new submission API
target_submit_cmd_map_sgls() is being removed, so convert vhost-scsi to the
new submission API. This has it use target_init_cmd(),
target_submit_prep(), target_submit() because we need to have LIO core map
sgls which is now done in target_submit_prep(), and in the next patches we
will do the target_submit step from the LIO workqueue.
Note: vhost-scsi never calls target_stop_session() so
target_submit_cmd_map_sgls() never failed (in the new API target_init_cmd()
handles target_stop_session() being called when cmds are being
submitted). If it were to have used target_stop_session() and got an error,
we would have hit a refcount bug like xen and usb, because it does:
if (rc < 0) {
transport_send_check_condition_and_sense(se_cmd,
TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, 0);
transport_generic_free_cmd(se_cmd, 0);
}
transport_send_check_condition_and_sense() calls queue_status which does
transport_generic_free_cmd(), and then we do an extra
transport_generic_free_cmd() call above which would have dropped the
refcount to -1 and the refcount code would spit out errors.
Link: https://lore.kernel.org/r/20210227170006.5077-12-michael.christie@oracle.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-02-27 10:59:52 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-27 10:59:56 -06:00
|
|
|
|
scsi: target: vhost-scsi: Convert to new submission API
target_submit_cmd_map_sgls() is being removed, so convert vhost-scsi to the
new submission API. This has it use target_init_cmd(),
target_submit_prep(), target_submit() because we need to have LIO core map
sgls which is now done in target_submit_prep(), and in the next patches we
will do the target_submit step from the LIO workqueue.
Note: vhost-scsi never calls target_stop_session() so
target_submit_cmd_map_sgls() never failed (in the new API target_init_cmd()
handles target_stop_session() being called when cmds are being
submitted). If it were to have used target_stop_session() and got an error,
we would have hit a refcount bug like xen and usb, because it does:
if (rc < 0) {
transport_send_check_condition_and_sense(se_cmd,
TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, 0);
transport_generic_free_cmd(se_cmd, 0);
}
transport_send_check_condition_and_sense() calls queue_status which does
transport_generic_free_cmd(), and then we do an extra
transport_generic_free_cmd() call above which would have dropped the
refcount to -1 and the refcount code would spit out errors.
Link: https://lore.kernel.org/r/20210227170006.5077-12-michael.christie@oracle.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-02-27 10:59:52 -06:00
|
|
|
|
|
|
|
|
|
2023-09-27 21:09:05 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-10 15:06:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
2018-12-13 09:10:14 +08:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code
from control queue handler") a null pointer dereference bug can be
triggered when guest sends an SCSI AN request.
In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with
`&v_req.tmf.lun[1]` within a switch-case block and is then passed to
vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for
a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is
set to NULL in this branch. Later, in vhost_scsi_get_req(),
`vc->target` is dereferenced without being checked, leading to a null
pointer dereference bug. This bug can be triggered from guest.
When this bug occurs, the vhost_worker process is killed while holding
`vq->mutex` and the corresponding tpg will remain occupied
indefinitely.
Below is the KASAN report:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vhost_scsi_get_req+0x165/0x3a0
Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6
04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00
RSP: 0018:ffff888017affb50 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8
RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000
FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0
Call Trace:
<TASK>
? show_regs+0x86/0xa0
? die_addr+0x4b/0xd0
? exc_general_protection+0x163/0x260
? asm_exc_general_protection+0x27/0x30
? vhost_scsi_get_req+0x165/0x3a0
vhost_scsi_ctl_handle_vq+0x2a4/0xca0
? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10
? __switch_to+0x721/0xeb0
? __schedule+0xda5/0x5710
? __kasan_check_write+0x14/0x30
? _raw_spin_lock+0x82/0xf0
vhost_scsi_ctl_handle_kick+0x52/0x90
vhost_run_work_list+0x134/0x1b0
vhost_task_fn+0x121/0x350
...
</TASK>
---[ end trace 0000000000000000 ]---
Let's add a check in vhost_scsi_get_req.
Fixes: 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler")
Signed-off-by: Haoran Zhang <wh1sper@zju.edu.cn>
[whitespace fixes]
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Message-Id: <b26d7ddd-b098-4361-88f8-17ca7f90adf7@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-10-01 15:14:15 -05:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code
from control queue handler") a null pointer dereference bug can be
triggered when guest sends an SCSI AN request.
In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with
`&v_req.tmf.lun[1]` within a switch-case block and is then passed to
vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for
a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is
set to NULL in this branch. Later, in vhost_scsi_get_req(),
`vc->target` is dereferenced without being checked, leading to a null
pointer dereference bug. This bug can be triggered from guest.
When this bug occurs, the vhost_worker process is killed while holding
`vq->mutex` and the corresponding tpg will remain occupied
indefinitely.
Below is the KASAN report:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vhost_scsi_get_req+0x165/0x3a0
Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6
04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00
RSP: 0018:ffff888017affb50 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8
RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000
FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0
Call Trace:
<TASK>
? show_regs+0x86/0xa0
? die_addr+0x4b/0xd0
? exc_general_protection+0x163/0x260
? asm_exc_general_protection+0x27/0x30
? vhost_scsi_get_req+0x165/0x3a0
vhost_scsi_ctl_handle_vq+0x2a4/0xca0
? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10
? __switch_to+0x721/0xeb0
? __schedule+0xda5/0x5710
? __kasan_check_write+0x14/0x30
? _raw_spin_lock+0x82/0xf0
vhost_scsi_ctl_handle_kick+0x52/0x90
vhost_run_work_list+0x134/0x1b0
vhost_task_fn+0x121/0x350
...
</TASK>
---[ end trace 0000000000000000 ]---
Let's add a check in vhost_scsi_get_req.
Fixes: 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler")
Signed-off-by: Haoran Zhang <wh1sper@zju.edu.cn>
[whitespace fixes]
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Message-Id: <b26d7ddd-b098-4361-88f8-17ca7f90adf7@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-10-01 15:14:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code
from control queue handler") a null pointer dereference bug can be
triggered when guest sends an SCSI AN request.
In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with
`&v_req.tmf.lun[1]` within a switch-case block and is then passed to
vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for
a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is
set to NULL in this branch. Later, in vhost_scsi_get_req(),
`vc->target` is dereferenced without being checked, leading to a null
pointer dereference bug. This bug can be triggered from guest.
When this bug occurs, the vhost_worker process is killed while holding
`vq->mutex` and the corresponding tpg will remain occupied
indefinitely.
Below is the KASAN report:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vhost_scsi_get_req+0x165/0x3a0
Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6
04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00
RSP: 0018:ffff888017affb50 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8
RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000
FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0
Call Trace:
<TASK>
? show_regs+0x86/0xa0
? die_addr+0x4b/0xd0
? exc_general_protection+0x163/0x260
? asm_exc_general_protection+0x27/0x30
? vhost_scsi_get_req+0x165/0x3a0
vhost_scsi_ctl_handle_vq+0x2a4/0xca0
? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10
? __switch_to+0x721/0xeb0
? __schedule+0xda5/0x5710
? __kasan_check_write+0x14/0x30
? _raw_spin_lock+0x82/0xf0
vhost_scsi_ctl_handle_kick+0x52/0x90
vhost_run_work_list+0x134/0x1b0
vhost_task_fn+0x121/0x350
...
</TASK>
---[ end trace 0000000000000000 ]---
Let's add a check in vhost_scsi_get_req.
Fixes: 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler")
Signed-off-by: Haoran Zhang <wh1sper@zju.edu.cn>
[whitespace fixes]
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Message-Id: <b26d7ddd-b098-4361-88f8-17ca7f90adf7@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-10-01 15:14:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:22 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-31 21:27:57 +02:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-17 00:29:52 -04:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-28 14:18:33 +02:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:22 -06:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:22 -06:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:21 -06:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-27 10:59:58 -06:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-17 00:29:52 -04:00
|
|
|
|
2018-09-17 17:09:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2018-12-03 16:48:23 -08:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2018-12-03 16:48:23 -08:00
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2018-12-03 16:48:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-15 19:47:03 -05:00
|
|
|
|
|
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:19 -05:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
2024-03-15 19:47:01 -05:00
|
|
|
|
2023-03-20 21:06:19 -05:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2018-12-03 16:48:23 -08:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-03 16:48:23 -08:00
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2018-12-03 16:48:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2019-05-17 00:29:52 -04:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-31 21:27:57 +02:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2019-05-17 00:29:52 -04:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-10 06:36:16 -04:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
2020-11-09 23:33:23 -06:00
|
|
|
|
2018-09-17 17:09:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-17 00:29:52 -04:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2018-09-17 17:09:47 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2023-06-26 18:23:00 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 10:37:33 +03:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-15 19:46:59 -05:00
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-31 21:27:57 +02:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 18:23:00 -05:00
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tcm_vhost: Multi-queue support
This adds virtio-scsi multi-queue support to tcm_vhost. In order to use
multi-queue, guest side multi-queue support is need. It can
be found here:
https://lkml.org/lkml/2012/12/18/166
Currently, only one thread is created by vhost core code for each
vhost_scsi instance. Even if there are multi-queues, all the handling of
guest kick (vhost_scsi_handle_kick) are processed in one thread. This is
not optimal. Luckily, most of the work is offloaded to the tcm_vhost
workqueue.
Some initial perf numbers:
1 queue, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 127K/127k IOPS
4 queues, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 181K/181k IOPS
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2013-02-06 13:20:59 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-28 15:38:52 +03:00
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
2022-05-17 13:08:50 -05:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
|
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-22 10:33:08 +08:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vhost-scsi: unbreak any layout for response
Al Viro said:
"""
Since "vhost/scsi: fix reuse of &vq->iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov,
cmd->tvc_in_iovs, sizeof(v_rsp));
in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov
_pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to
set an iovec-backed iov_iter over the tail of vq->iov[], with
length being the amount of iovecs in the tail.
Now we have a copy of one element of that array. Fortunately, the members
following it in the containing structure are two non-NULL kernel pointers,
so copy_to_iter() will not copy anything beyond the first iovec - kernel
pointer is not (on the majority of architectures) going to be accepted by
access_ok() in copyout() and it won't be skipped since the "length" (in
reality - another non-NULL kernel pointer) won't be zero.
So it's not going to give a guest-to-qemu escalation, but it's definitely
a bug. Frankly, my preference would be to verify that the very first iovec
is long enough to hold rsp_size. Due to the above, any users that try to
give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp)
would currently get a failure in vhost_scsi_complete_cmd_work()
anyway.
"""
However, the spec doesn't say anything about the legacy descriptor
layout for the respone. So this patch tries to not assume the response
to reside in a single separate descriptor which is what commit
79c14141a487 ("vhost/scsi: Convert completion path to use") tries to
achieve towards to ANY_LAYOUT.
This is done by allocating and using dedicate resp iov in the
command. To be safety, start with UIO_MAXIOV to be consistent with the
limitation that we advertise to the vhost_get_vq_desc().
Testing with the hacked virtio-scsi driver that use 1 descriptor for 1
byte in the response.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20230119073647.76467-1-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-19 15:36:47 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:20 +08:00
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:24 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2014-10-08 06:19:20 +00:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:20 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2013-04-25 15:35:20 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:20 +08:00
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:24 -05:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:24 -05:00
|
|
|
|
2013-04-25 15:35:20 +08:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2014-10-08 06:19:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-03 08:50:52 +02:00
|
|
|
|
2014-10-08 06:19:20 +00:00
|
|
|
|
2018-12-13 09:10:14 +08:00
|
|
|
|
2014-10-08 06:19:20 +00:00
|
|
|
|
2023-03-20 21:06:24 -05:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2014-10-08 06:19:20 +00:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-03-20 21:06:24 -05:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-04 16:43:30 +08:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
2020-03-31 21:27:57 +02:00
|
|
|
|
2016-02-16 15:59:44 +01:00
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:18 -05:00
|
|
|
|
|
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2023-03-20 21:06:18 -05:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:20 +08:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2014-10-08 06:19:20 +00:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2013-03-15 09:14:05 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:20 +08:00
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:20 -05:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
|
|
|
|
|
2023-03-20 21:06:20 -05:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2023-03-20 21:06:20 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2023-03-20 21:06:20 -05:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2023-03-20 21:06:20 -05:00
|
|
|
|
2014-10-08 06:19:20 +00:00
|
|
|
|
2015-05-03 08:50:52 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2021-05-25 12:47:31 -05:00
|
|
|
|
2023-03-20 21:06:20 -05:00
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2013-03-15 09:14:05 +08:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
2014-06-05 15:20:23 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-05 15:20:23 +03:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2014-06-05 15:20:23 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-03 14:17:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
2013-05-06 16:38:26 +08:00
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2021-01-23 00:08:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-17 09:30:34 +03:00
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2013-05-06 16:38:26 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:26 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2023-06-26 18:22:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
2020-05-29 16:02:58 +08:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-27 11:16:49 +08:00
|
|
|
|
2013-05-06 16:38:26 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-09-17 09:30:34 +03:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
2013-09-17 09:30:34 +03:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
2014-06-12 19:00:01 +03:00
|
|
|
|
2013-09-17 09:30:34 +03:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:26 +08:00
|
|
|
|
2013-02-05 12:31:57 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:26 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-25 00:08:58 +08:00
|
|
|
|
2013-05-06 16:38:26 +08:00
|
|
|
|
2022-07-07 22:05:25 -05:00
|
|
|
|
|
|
|
|
|
2014-06-12 19:00:01 +03:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:22 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-18 15:44:09 -07:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-18 15:44:09 -07:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-25 15:35:22 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-03-27 17:23:41 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 18:23:06 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2012-12-06 14:03:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-11 17:23:00 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-30 15:59:57 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-07-30 15:59:57 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-27 11:16:48 +08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2023-03-20 21:06:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-05 15:20:23 +03:00
|
|
|
|
2023-06-26 18:23:00 -05:00
|
|
|
|
2014-06-05 15:20:23 +03:00
|
|
|
|
2023-03-20 21:06:22 -05:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2023-03-20 21:06:23 -05:00
|
|
|
|
2013-04-25 15:35:21 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2023-03-20 21:06:23 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
|
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
|
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-29 04:11:45 -05:00
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
|
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
|
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-20 13:48:44 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-09 05:47:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2016-01-09 05:47:55 -08:00
|
|
|
|
2020-11-09 23:33:20 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-06-21 14:32:04 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2018-08-02 12:12:27 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2023-01-29 04:11:45 -05:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2013-05-06 16:38:28 +08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2018-06-22 14:53:02 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2015-02-05 10:37:33 +03:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 10:37:33 +03:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2017-05-20 13:48:44 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-20 21:48:03 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2012-07-30 13:30:00 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2017-05-20 13:48:44 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-06 16:38:27 +08:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2023-01-29 04:11:45 -05:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2015-10-03 15:32:55 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-09 20:51:02 +05:30
|
|
|
|
2015-04-08 20:01:35 +02:00
|
|
|
|
2018-11-23 18:36:12 +01:00
|
|
|
|
2020-05-22 16:51:57 +00:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-28 00:03:51 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2013-06-06 02:20:41 -07:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-04-08 20:01:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-27 21:09:01 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2015-04-08 20:01:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
2021-02-27 10:59:58 -06:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-04-08 20:01:35 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-04-08 20:01:35 +02:00
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-02 03:52:59 +03:00
|
|
|
|
|
|
|
|
|
2012-07-18 14:31:32 -07:00
|
|
|
|
2015-01-31 23:56:53 -08:00
|
|
|
|
|
|
|
|
|