[PATCH AUTOSEL 6.3 28/30] tools/virtio: Fix arm64 ringtest compilation error
From: Rong Tao
[ Upstream commit 57380fd1249b20ef772549af2c58ef57b21faba7 ]
Add cpu_relax() for arm64 instead of directly assert(), and add assert.h
header file. Also, add smp_wmb and smp_mb for arm64.
Compilation error as follows, avoid __always_inline undefined.
$ make
cc -Wall -pthread -O2 -ggdb -flto -fwhole-program -c -o ring.o ring.c
In file included from ring.c:10:
main.h: In function ‘busy_wait’:
main.h:99:21: warning: implicit declaration of function ‘assert’
[-Wimplicit-function-declaration]
99 | #define cpu_relax() assert(0)
| ^~
main.h:107:17: note: in expansion of macro ‘cpu_relax’
107 | cpu_relax();
| ^
main.h:12:1: note: ‘assert’ is defined in header ‘’; did you
forget to ‘#include ’?
11 | #include
+++ |+#include
12 |
main.h: At top level:
main.h:143:23: error: expected ‘;’ before ‘void’
143 | static __always_inline
| ^
| ;
144 | void __read_once_size(const volatile void *p, void *res, int
size)
|
main.h:158:23: error: expected ‘;’ before ‘void’
158 | static __always_inline void __write_once_size(volatile void *p,
void *res, int size)
| ^
| ;
make: *** [: ring.o] Error 1
Signed-off-by: Rong Tao
Message-Id:
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
tools/virtio/ringtest/main.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/virtio/ringtest/main.h b/tools/virtio/ringtest/main.h
index b68920d527503..d18dd317e27f9 100644
--- a/tools/virtio/ringtest/main.h
+++ b/tools/virtio/ringtest/main.h
@@ -8,6 +8,7 @@
#ifndef MAIN_H
#define MAIN_H
+#include
#include
extern int param;
@@ -95,6 +96,8 @@ extern unsigned ring_size;
#define cpu_relax() asm ("rep; nop" ::: "memory")
#elif defined(__s390x__)
#define cpu_relax() barrier()
+#elif defined(__aarch64__)
+#define cpu_relax() asm ("yield" ::: "memory")
#else
#define cpu_relax() assert(0)
#endif
@@ -112,6 +115,8 @@ static inline void busy_wait(void)
#if defined(__x86_64__) || defined(__i386__)
#define smp_mb() asm volatile("lock; addl $0,-132(%%rsp)" ::: "memory",
"cc")
+#elif defined(__aarch64__)
+#define smp_mb() asm volatile("dmb ish" ::: "memory")
#else
/*
* Not using __ATOMIC_SEQ_CST since gcc docs say they are only synchronized
@@ -136,10 +141,16 @@ static inline void busy_wait(void)
#if defined(__i386__) || defined(__x86_64__) || defined(__s390x__)
#define smp_wmb() barrier()
+#elif defined(__aarch64__)
+#define smp_wmb() asm volatile("dmb ishst" ::: "memory")
#else
#define smp_wmb() smp_release()
#endif
+#ifndef __always_inline
+#define __always_inline inline __attribute__((always_inline))
+#endif
+
static __always_inline
void __read_once_size(const volatile void *p, void *res, int size)
{
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.3 30/30] vhost_net: revert upend_idx only on retriable error
From: Andrey Smetanin
[ Upstream commit 1f5d2e3bab16369d5d4b4020a25db4ab1f4f082c ]
Fix possible virtqueue used buffers leak and corresponding stuck
in case of temporary -EIO from sendmsg() which is produced by
tun driver while backend device is not up.
In case of no-retriable error and zcopy do not revert upend_idx
to pass packet data (that is update used_idx in corresponding
vhost_zerocopy_signal_used()) as if packet data has been
transferred successfully.
v2: set vq->heads[ubuf->desc].len equal to VHOST_DMA_DONE_LEN
in case of fake successful transmit.
Signed-off-by: Andrey Smetanin
Message-Id: <20230424204411.24888-1-asmeta...@yandex-team.ru>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Andrey Smetanin
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vhost/net.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 07181cd8d52e6..ae2273196b0c9 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -935,13 +935,18 @@ static void handle_tx_zerocopy(struct vhost_net *net,
struct socket *sock)
err = sock->ops->sendmsg(sock, &msg, len);
if (unlikely(err < 0)) {
+ bool retry = err == -EAGAIN || err == -ENOMEM || err ==
-ENOBUFS;
+
if (zcopy_used) {
if (vq->heads[ubuf->desc].len ==
VHOST_DMA_IN_PROGRESS)
vhost_net_ubuf_put(ubufs);
- nvq->upend_idx = ((unsigned)nvq->upend_idx - 1)
- % UIO_MAXIOV;
+ if (retry)
+ nvq->upend_idx =
((unsigned)nvq->upend_idx - 1)
+ % UIO_MAXIOV;
+ else
+ vq->heads[ubuf->desc].len =
VHOST_DMA_DONE_LEN;
}
- if (err == -EAGAIN || err == -ENOMEM || err ==
-ENOBUFS) {
+ if (retry) {
vhost_discard_vq_desc(vq, 1);
vhost_net_enable_vq(net, vq);
break;
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.3 29/30] vhost_vdpa: tell vqs about the negotiated
From: Shannon Nelson
[ Upstream commit 376daf317753ccb6b1ecbdece66018f7f6313a7f ]
As is done in the net, iscsi, and vsock vhost support, let the vdpa vqs
know about the features that have been negotiated. This allows vhost
to more safely make decisions based on the features, such as when using
PACKED vs split queues.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
Message-Id: <20230424225031.18947-2-shannon.nel...@amd.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/vhost/vdpa.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 74c7d1f978b75..a5e4722cbeda1 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -385,7 +385,10 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
{
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
+ struct vhost_dev *d = &v->vdev;
+ u64 actual_features;
u64 features;
+ int i;
/*
* It's not allowed to change the features after they have
@@ -400,6 +403,16 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
if (vdpa_set_features(vdpa, features))
return -EINVAL;
+ /* let the vqs know what has been configured */
+ actual_features = ops->get_driver_features(vdpa);
+ for (i = 0; i < d->nvqs; ++i) {
+ struct vhost_virtqueue *vq = d->vqs[i];
+
+ mutex_lock(&vq->mutex);
+ vq->acked_features = actual_features;
+ mutex_unlock(&vq->mutex);
+ }
+
return 0;
}
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.1 25/26] vhost_vdpa: tell vqs about the negotiated
From: Shannon Nelson
[ Upstream commit 376daf317753ccb6b1ecbdece66018f7f6313a7f ]
As is done in the net, iscsi, and vsock vhost support, let the vdpa vqs
know about the features that have been negotiated. This allows vhost
to more safely make decisions based on the features, such as when using
PACKED vs split queues.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
Message-Id: <20230424225031.18947-2-shannon.nel...@amd.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/vhost/vdpa.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 6f532da59e08a..57f7c71da571c 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -377,7 +377,10 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
{
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
+ struct vhost_dev *d = &v->vdev;
+ u64 actual_features;
u64 features;
+ int i;
/*
* It's not allowed to change the features after they have
@@ -392,6 +395,16 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
if (vdpa_set_features(vdpa, features))
return -EINVAL;
+ /* let the vqs know what has been configured */
+ actual_features = ops->get_driver_features(vdpa);
+ for (i = 0; i < d->nvqs; ++i) {
+ struct vhost_virtqueue *vq = d->vqs[i];
+
+ mutex_lock(&vq->mutex);
+ vq->acked_features = actual_features;
+ mutex_unlock(&vq->mutex);
+ }
+
return 0;
}
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.1 26/26] vhost_net: revert upend_idx only on retriable error
From: Andrey Smetanin
[ Upstream commit 1f5d2e3bab16369d5d4b4020a25db4ab1f4f082c ]
Fix possible virtqueue used buffers leak and corresponding stuck
in case of temporary -EIO from sendmsg() which is produced by
tun driver while backend device is not up.
In case of no-retriable error and zcopy do not revert upend_idx
to pass packet data (that is update used_idx in corresponding
vhost_zerocopy_signal_used()) as if packet data has been
transferred successfully.
v2: set vq->heads[ubuf->desc].len equal to VHOST_DMA_DONE_LEN
in case of fake successful transmit.
Signed-off-by: Andrey Smetanin
Message-Id: <20230424204411.24888-1-asmeta...@yandex-team.ru>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Andrey Smetanin
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vhost/net.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 4c538b30fd76d..4418192ab8aaa 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -934,13 +934,18 @@ static void handle_tx_zerocopy(struct vhost_net *net,
struct socket *sock)
err = sock->ops->sendmsg(sock, &msg, len);
if (unlikely(err < 0)) {
+ bool retry = err == -EAGAIN || err == -ENOMEM || err ==
-ENOBUFS;
+
if (zcopy_used) {
if (vq->heads[ubuf->desc].len ==
VHOST_DMA_IN_PROGRESS)
vhost_net_ubuf_put(ubufs);
- nvq->upend_idx = ((unsigned)nvq->upend_idx - 1)
- % UIO_MAXIOV;
+ if (retry)
+ nvq->upend_idx =
((unsigned)nvq->upend_idx - 1)
+ % UIO_MAXIOV;
+ else
+ vq->heads[ubuf->desc].len =
VHOST_DMA_DONE_LEN;
}
- if (err == -EAGAIN || err == -ENOMEM || err ==
-ENOBUFS) {
+ if (retry) {
vhost_discard_vq_desc(vq, 1);
vhost_net_enable_vq(net, vq);
break;
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 15/16] vhost_vdpa: tell vqs about the negotiated
From: Shannon Nelson
[ Upstream commit 376daf317753ccb6b1ecbdece66018f7f6313a7f ]
As is done in the net, iscsi, and vsock vhost support, let the vdpa vqs
know about the features that have been negotiated. This allows vhost
to more safely make decisions based on the features, such as when using
PACKED vs split queues.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
Message-Id: <20230424225031.18947-2-shannon.nel...@amd.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/vhost/vdpa.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 299a995326185..1f9670e6ecec2 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -278,7 +278,10 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
{
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
+ struct vhost_dev *d = &v->vdev;
+ u64 actual_features;
u64 features;
+ int i;
/*
* It's not allowed to change the features after they have
@@ -293,6 +296,16 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
if (vdpa_set_features(vdpa, features))
return -EINVAL;
+ /* let the vqs know what has been configured */
+ actual_features = ops->get_driver_features(vdpa);
+ for (i = 0; i < d->nvqs; ++i) {
+ struct vhost_virtqueue *vq = d->vqs[i];
+
+ mutex_lock(&vq->mutex);
+ vq->acked_features = actual_features;
+ mutex_unlock(&vq->mutex);
+ }
+
return 0;
}
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 16/16] vhost_net: revert upend_idx only on retriable error
From: Andrey Smetanin
[ Upstream commit 1f5d2e3bab16369d5d4b4020a25db4ab1f4f082c ]
Fix possible virtqueue used buffers leak and corresponding stuck
in case of temporary -EIO from sendmsg() which is produced by
tun driver while backend device is not up.
In case of no-retriable error and zcopy do not revert upend_idx
to pass packet data (that is update used_idx in corresponding
vhost_zerocopy_signal_used()) as if packet data has been
transferred successfully.
v2: set vq->heads[ubuf->desc].len equal to VHOST_DMA_DONE_LEN
in case of fake successful transmit.
Signed-off-by: Andrey Smetanin
Message-Id: <20230424204411.24888-1-asmeta...@yandex-team.ru>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Andrey Smetanin
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vhost/net.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 32148f0112004..00f10d3402590 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -933,13 +933,18 @@ static void handle_tx_zerocopy(struct vhost_net *net,
struct socket *sock)
err = sock->ops->sendmsg(sock, &msg, len);
if (unlikely(err < 0)) {
+ bool retry = err == -EAGAIN || err == -ENOMEM || err ==
-ENOBUFS;
+
if (zcopy_used) {
if (vq->heads[ubuf->desc].len ==
VHOST_DMA_IN_PROGRESS)
vhost_net_ubuf_put(ubufs);
- nvq->upend_idx = ((unsigned)nvq->upend_idx - 1)
- % UIO_MAXIOV;
+ if (retry)
+ nvq->upend_idx =
((unsigned)nvq->upend_idx - 1)
+ % UIO_MAXIOV;
+ else
+ vq->heads[ubuf->desc].len =
VHOST_DMA_DONE_LEN;
}
- if (err == -EAGAIN || err == -ENOMEM || err ==
-ENOBUFS) {
+ if (retry) {
vhost_discard_vq_desc(vq, 1);
vhost_net_enable_vq(net, vq);
break;
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 14/14] vhost_vdpa: tell vqs about the negotiated
From: Shannon Nelson
[ Upstream commit 376daf317753ccb6b1ecbdece66018f7f6313a7f ]
As is done in the net, iscsi, and vsock vhost support, let the vdpa vqs
know about the features that have been negotiated. This allows vhost
to more safely make decisions based on the features, such as when using
PACKED vs split queues.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
Message-Id: <20230424225031.18947-2-shannon.nel...@amd.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/vhost/vdpa.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 04578aa87e4da..d3a7a5a2f207b 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -281,7 +281,10 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
{
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
+ struct vhost_dev *d = &v->vdev;
+ u64 actual_features;
u64 features;
+ int i;
/*
* It's not allowed to change the features after they have
@@ -296,6 +299,16 @@ static long vhost_vdpa_set_features(struct vhost_vdpa *v,
u64 __user *featurep)
if (vdpa_set_features(vdpa, features))
return -EINVAL;
+ /* let the vqs know what has been configured */
+ actual_features = ops->get_driver_features(vdpa);
+ for (i = 0; i < d->nvqs; ++i) {
+ struct vhost_virtqueue *vq = d->vqs[i];
+
+ mutex_lock(&vq->mutex);
+ vq->acked_features = actual_features;
+ mutex_unlock(&vq->mutex);
+ }
+
return 0;
}
--
2.39.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.3 15/17] Revert "virtio-blk: support completion batching for the IRQ path"
From: "Michael S. Tsirkin"
[ Upstream commit afd384f0dbea2229fd11159efb86a5b41051c4a9 ]
This reverts commit 07b679f70d73483930e8d3c293942416d9cd5c13.
This change appears to have broken things...
We now see applications hanging during disk accesses.
e.g.
multi-port virtio-blk device running in h/w (FPGA)
Host running a simple 'fio' test.
[global]
thread=1
direct=1
ioengine=libaio
norandommap=1
group_reporting=1
bs=4K
rw=read
iodepth=128
runtime=1
numjobs=4
time_based
[job0]
filename=/dev/vda
[job1]
filename=/dev/vdb
[job2]
filename=/dev/vdc
...
[job15]
filename=/dev/vdp
i.e. 16 disks; 4 queues per disk; simple burst of 4KB reads
This is repeatedly run in a loop.
After a few, normally <10 seconds, fio hangs.
With 64 queues (16 disks), failure occurs within a few seconds; with 8 queues
(2 disks) it may take ~hour before hanging.
Last message:
fio-3.19
Starting 8 threads
Jobs: 1 (f=1): [_(7),R(1)][68.3%][eta 03h:11m:06s]
I think this means at the end of the run 1 queue was left incomplete.
'diskstats' (run while fio is hung) shows no outstanding transactions.
e.g.
$ cat /proc/diskstats
...
252 0 vda 1843140071 0 14745120568 712568645 0 0 0 0 0 3117947 712568645
0 0 0 0 0 0
252 16 vdb 1816291511 0 14530332088 704905623 0 0 0 0 0 3117711 704905623
0 0 0 0 0 0
...
Other stats (in the h/w, and added to the virtio-blk driver
([a]virtio_queue_rq(), [b]virtblk_handle_req(), [c]virtblk_request_done()) all
agree, and show every request had a completion, and that virtblk_request_done()
never gets called.
e.g.
PF= 0 vq=0 1 2 3
[a]request_count - 839416590 813148916 10558617984988123
[b]completion1_count - 839416590 813148916 10558617984988123
[c]completion2_count - 0 0 0 0
PF= 1 vq=0 1 2 3
[a]request_count - 823335887 812516140 10458267275856549
[b]completion1_count - 823335887 812516140 10458267275856549
[c]completion2_count - 0 0 0 0
i.e. the issue is after the virtio-blk driver.
This change was introduced in kernel 6.3.0.
I am seeing this using 6.3.3.
If I run with an earlier kernel (5.15), it does not occur.
If I make a simple patch to the 6.3.3 virtio-blk driver, to skip the
blk_mq_add_to_batch()call, it does not fail.
e.g.
kernel 5.15 - this is OK
virtio_blk.c,virtblk_done() [irq handler]
if (likely(!blk_should_fake_timeout(req->q))) {
blk_mq_complete_request(req);
}
kernel 6.3.3 - this fails
virtio_blk.c,virtblk_handle_req() [irq handler]
if (likely(!blk_should_fake_timeout(req->q))) {
if (!blk_mq_complete_request_remote(req)) {
if (!blk_mq_add_to_batch(req, iob,
virtblk_vbr_status(vbr), virtblk_complete_batch)) {
virtblk_request_done(req);//this
never gets called... so blk_mq_add_to_batch() must always succeed
}
}
}
If I do, kernel 6.3.3 - this is OK
virtio_blk.c,virtblk_handle_req() [irq handler]
if (likely(!blk_should_fake_timeout(req->q))) {
if (!blk_mq_complete_request_remote(req)) {
virtblk_request_done(req); //force this
here...
if (!blk_mq_add_to_batch(req, iob,
virtblk_vbr_status(vbr), virtblk_complete_batch)) {
virtblk_request_done(req);//this
never gets called... so blk_mq_add_to_batch() must always succeed
}
}
}
Perhaps you might like to fix/test/revert this change...
Martin
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202306090826.c1fzmdme-...@intel.com/
Cc: Suwan Kim
Tested-by: edl...@google.com
Reported-by: "Roberts, Martin"
Message-Id:
<336455b4f630f329380a8f53ee8cad3868764d5c.1686295549.git@redhat.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/block/virtio_blk.c | 82 +-
1 file changed, 37 insertions(+), 45 deletions(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 2b918e28acaac..b47358da92a23 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -348,63 +348,33 @@ static inline void virtblk_request_done(struct request
*req)
blk_mq_end_request(req, status);
}
-static void virtblk_complete_batch(struct io_comp_batch *iob)
-{
- struct request *req;
-
- rq_list_for_each(&iob->req_list, req) {
- virtblk_unmap_data(req, blk_mq_rq_to_pdu(req));
- virtblk_cleanup_cmd(re
[PATCH AUTOSEL 6.4 05/17] vdpa/mlx5: Correct default number of queues when MQ is on
From: Dragos Tatulea [ Upstream commit 3fe024193340b225d1fd410d78c495434a9d68e0 ] The standard specifies that the initial number of queues is the default, which is 1 (1 tx, 1 rx). Signed-off-by: Dragos Tatulea Reviewed-by: Eugenio Pérez Message-Id: <20230727172354.68243-2-dtatu...@nvidia.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Tested-by: Lei Yang Signed-off-by: Sasha Levin --- drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c index 279ac6a558d29..93a2520223b66 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -2447,7 +2447,15 @@ static int mlx5_vdpa_set_driver_features(struct vdpa_device *vdev, u64 features) else ndev->rqt_size = 1; - ndev->cur_num_vqs = 2 * ndev->rqt_size; + /* Device must start with 1 queue pair, as per VIRTIO v1.2 spec, section +* 5.1.6.5.5 "Device operation in multiqueue mode": +* +* Multiqueue is disabled by default. +* The driver enables multiqueue by sending a command using class +* VIRTIO_NET_CTRL_MQ. The command selects the mode of multiqueue +* operation, as follows: ... +*/ + ndev->cur_num_vqs = 2; update_cvq_info(mvdev); return err; -- 2.40.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.4 04/17] vhost-scsi: Fix alignment handling with windows
From: Mike Christie
[ Upstream commit 5ced58bfa132c8ba0f9c893eb621595a84cfee12 ]
The linux block layer requires bios/requests to have lengths with a 512
byte alignment. Some drivers/layers like dm-crypt and the directi IO code
will test for it and just fail. Other drivers like SCSI just assume the
requirement is met and will end up in infinte retry loops. The problem
for drivers like SCSI is that it uses functions like blk_rq_cur_sectors
and blk_rq_sectors which divide the request's length by 512. If there's
lefovers then it just gets dropped. But other code in the block/scsi
layer may use blk_rq_bytes/blk_rq_cur_bytes and end up thinking there is
still data left and try to retry the cmd. We can then end up getting
stuck in retry loops where part of the block/scsi thinks there is data
left, but other parts think we want to do IOs of zero length.
Linux will always check for alignment, but windows will not. When
vhost-scsi then translates the iovec it gets from a windows guest to a
scatterlist, we can end up with sg items where the sg->length is not
divisible by 512 due to the misaligned offset:
sg[0].offset = 255;
sg[0].length = 3841;
sg...
sg[N].offset = 0;
sg[N].length = 255;
When the lio backends then convert the SG to bios or other iovecs, we
end up sending them with the same misaligned values and can hit the
issues above.
This just has us drop down to allocating a temp page and copying the data
when we detect a misaligned buffer and the IO is large enough that it
will get split into multiple bad IOs.
Signed-off-by: Mike Christie
Message-Id: <20230709202859.138387-2-michael.chris...@oracle.com>
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 186 +--
1 file changed, 161 insertions(+), 25 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index bb10fa4bb4f6e..fa19c3f043b12 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -75,6 +77,9 @@ struct vhost_scsi_cmd {
u32 tvc_prot_sgl_count;
/* Saved unpacked SCSI LUN for vhost_scsi_target_queue_cmd() */
u32 tvc_lun;
+ u32 copied_iov:1;
+ const void *saved_iter_addr;
+ struct iov_iter saved_iter;
/* Pointer to the SGL formatted memory from virtio-scsi */
struct scatterlist *tvc_sgl;
struct scatterlist *tvc_prot_sgl;
@@ -328,8 +333,13 @@ static void vhost_scsi_release_cmd_res(struct se_cmd
*se_cmd)
int i;
if (tv_cmd->tvc_sgl_count) {
- for (i = 0; i < tv_cmd->tvc_sgl_count; i++)
- put_page(sg_page(&tv_cmd->tvc_sgl[i]));
+ for (i = 0; i < tv_cmd->tvc_sgl_count; i++) {
+ if (tv_cmd->copied_iov)
+ __free_page(sg_page(&tv_cmd->tvc_sgl[i]));
+ else
+ put_page(sg_page(&tv_cmd->tvc_sgl[i]));
+ }
+ kfree(tv_cmd->saved_iter_addr);
}
if (tv_cmd->tvc_prot_sgl_count) {
for (i = 0; i < tv_cmd->tvc_prot_sgl_count; i++)
@@ -502,6 +512,28 @@ static void vhost_scsi_evt_work(struct vhost_work *work)
mutex_unlock(&vq->mutex);
}
+static int vhost_scsi_copy_sgl_to_iov(struct vhost_scsi_cmd *cmd)
+{
+ struct iov_iter *iter = &cmd->saved_iter;
+ struct scatterlist *sg = cmd->tvc_sgl;
+ struct page *page;
+ size_t len;
+ int i;
+
+ for (i = 0; i < cmd->tvc_sgl_count; i++) {
+ page = sg_page(&sg[i]);
+ len = sg[i].length;
+
+ if (copy_page_to_iter(page, 0, len, iter) != len) {
+ pr_err("Could not copy data while handling misaligned
cmd. Error %zu\n",
+ len);
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
/* Fill in status and signal that we are done processing this command
*
* This is scheduled in the vhost work queue so we are called with the owner
@@ -525,15 +557,20 @@ static void vhost_scsi_complete_cmd_work(struct
vhost_work *work)
pr_debug("%s tv_cmd %p resid %u status %#02x\n", __func__,
cmd, se_cmd->residual_count, se_cmd->scsi_status);
-
memset(&v_rsp, 0, sizeof(v_rsp));
- v_rsp.resid = cpu_to_vhost32(cmd->tvc_vq,
se_cmd->residual_count);
- /* TODO is status_qualifier field needed? */
- v_rsp.status = se_cmd->scsi_status;
- v_rsp.sense_len = cpu_to_vhost32(cmd->tvc_vq,
-se_cmd->scsi_sense_length);
- memcpy(v_rsp.sense, cmd-&
[PATCH AUTOSEL 6.4 07/17] virtio-mem: convert most offline_and_remove_memory() errors to -EBUSY
From: David Hildenbrand
[ Upstream commit ddf409851461f515cc32974714b73efe2e012bde ]
Just like we do with alloc_contig_range(), let's convert all unknown
errors to -EBUSY, but WARN so we can look into the issue. For example,
offline_pages() could fail with -EINTR, which would be unexpected in our
case.
Signed-off-by: David Hildenbrand
Message-Id: <20230713145551.2824980-3-da...@redhat.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_mem.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index ed15d2a4bd96b..1a76ba2bc118c 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -741,11 +741,15 @@ static int virtio_mem_offline_and_remove_memory(struct
virtio_mem *vm,
* immediately instead of waiting.
*/
virtio_mem_retry(vm);
- } else {
- dev_dbg(&vm->vdev->dev,
- "offlining and removing memory failed: %d\n", rc);
+ return 0;
}
- return rc;
+ dev_dbg(&vm->vdev->dev, "offlining and removing memory failed: %d\n",
rc);
+ /*
+* We don't really expect this to fail, because we fake-offlined all
+* memory already. But it could fail in corner cases.
+*/
+ WARN_ON_ONCE(rc != -ENOMEM && rc != -EBUSY);
+ return rc == -ENOMEM ? -ENOMEM : -EBUSY;
}
/*
--
2.40.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.4 08/17] virtio-mem: keep retrying on offline_and_remove_memory() errors in Sub Block Mode (SBM)
From: David Hildenbrand
[ Upstream commit a31648fd4f96fbe0a4d0aeb16b57a2405c6943c0 ]
In case offline_and_remove_memory() fails in SBM, we leave a completely
unplugged Linux memory block stick around until we try plugging memory
again. We won't try removing that memory block again.
offline_and_remove_memory() may, for example, fail if we're racing with
another alloc_contig_range() user, if allocating temporary memory fails,
or if some memory notifier rejected the offlining request.
Let's handle that case better, by simple retrying to offline and remove
such memory.
Tested using CONFIG_MEMORY_NOTIFIER_ERROR_INJECT.
Signed-off-by: David Hildenbrand
Message-Id: <20230713145551.2824980-4-da...@redhat.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_mem.c | 92 +
1 file changed, 73 insertions(+), 19 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 1a76ba2bc118c..a5cf92e3e5af2 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -168,6 +168,13 @@ struct virtio_mem {
/* The number of subblocks per Linux memory block. */
uint32_t sbs_per_mb;
+ /*
+* Some of the Linux memory blocks tracked as "partially
+* plugged" are completely unplugged and can be offlined
+* and removed -- which previously failed.
+*/
+ bool have_unplugged_mb;
+
/* Summary of all memory block states. */
unsigned long mb_count[VIRTIO_MEM_SBM_MB_COUNT];
@@ -765,6 +772,34 @@ static int virtio_mem_sbm_offline_and_remove_mb(struct
virtio_mem *vm,
return virtio_mem_offline_and_remove_memory(vm, addr, size);
}
+/*
+ * Try (offlining and) removing memory from Linux in case all subblocks are
+ * unplugged. Can be called on online and offline memory blocks.
+ *
+ * May modify the state of memory blocks in virtio-mem.
+ */
+static int virtio_mem_sbm_try_remove_unplugged_mb(struct virtio_mem *vm,
+ unsigned long mb_id)
+{
+ int rc;
+
+ /*
+* Once all subblocks of a memory block were unplugged, offline and
+* remove it.
+*/
+ if (!virtio_mem_sbm_test_sb_unplugged(vm, mb_id, 0, vm->sbm.sbs_per_mb))
+ return 0;
+
+ /* offline_and_remove_memory() works for online and offline memory. */
+ mutex_unlock(&vm->hotplug_mutex);
+ rc = virtio_mem_sbm_offline_and_remove_mb(vm, mb_id);
+ mutex_lock(&vm->hotplug_mutex);
+ if (!rc)
+ virtio_mem_sbm_set_mb_state(vm, mb_id,
+ VIRTIO_MEM_SBM_MB_UNUSED);
+ return rc;
+}
+
/*
* See virtio_mem_offline_and_remove_memory(): Try to offline and remove a
* all Linux memory blocks covered by the big block.
@@ -1988,20 +2023,10 @@ static int virtio_mem_sbm_unplug_any_sb_online(struct
virtio_mem *vm,
}
unplugged:
- /*
-* Once all subblocks of a memory block were unplugged, offline and
-* remove it. This will usually not fail, as no memory is in use
-* anymore - however some other notifiers might NACK the request.
-*/
- if (virtio_mem_sbm_test_sb_unplugged(vm, mb_id, 0, vm->sbm.sbs_per_mb))
{
- mutex_unlock(&vm->hotplug_mutex);
- rc = virtio_mem_sbm_offline_and_remove_mb(vm, mb_id);
- mutex_lock(&vm->hotplug_mutex);
- if (!rc)
- virtio_mem_sbm_set_mb_state(vm, mb_id,
- VIRTIO_MEM_SBM_MB_UNUSED);
- }
-
+ rc = virtio_mem_sbm_try_remove_unplugged_mb(vm, mb_id);
+ if (rc)
+ vm->sbm.have_unplugged_mb = 1;
+ /* Ignore errors, this is not critical. We'll retry later. */
return 0;
}
@@ -2253,12 +2278,13 @@ static int virtio_mem_unplug_request(struct virtio_mem
*vm, uint64_t diff)
/*
* Try to unplug all blocks that couldn't be unplugged before, for example,
- * because the hypervisor was busy.
+ * because the hypervisor was busy. Further, offline and remove any memory
+ * blocks where we previously failed.
*/
-static int virtio_mem_unplug_pending_mb(struct virtio_mem *vm)
+static int virtio_mem_cleanup_pending_mb(struct virtio_mem *vm)
{
unsigned long id;
- int rc;
+ int rc = 0;
if (!vm->in_sbm) {
virtio_mem_bbm_for_each_bb(vm, id,
@@ -2280,6 +2306,27 @@ static int virtio_mem_unplug_pending_mb(struct
virtio_mem *vm)
VIRTIO_MEM_SBM_MB_UNUSED);
}
+ if (!vm->sbm.have_unplugged_mb)
+ return 0;
+
+
[PATCH AUTOSEL 6.4 06/17] virtio-mem: remove unsafe unplug in Big Block Mode (BBM)
From: David Hildenbrand
[ Upstream commit f504e15b94eb4e5b47f8715da59c0207f68dffe1 ]
When "unsafe unplug" is enabled, we don't fake-offline all memory ahead of
actual memory offlining using alloc_contig_range(). Instead, we rely on
offline_pages() to also perform actual page migration, which might fail
or take a very long time.
In that case, it's possible to easily run into endless loops that cannot be
aborted anymore (as offlining is triggered by a workqueue then): For
example, a single (accidentally) permanently unmovable page in
ZONE_MOVABLE results in an endless loop. For ZONE_NORMAL, races between
isolating the pageblock (and checking for unmovable pages) and
concurrent page allocation are possible and similarly result in endless
loops.
The idea of the unsafe unplug mode was to make it possible to more
reliably unplug large memory blocks. However, (a) we really should be
tackling that differently, by extending the alloc_contig_range()-based
mechanism; and (b) this mode is not the default and as far as I know,
it's unused either way.
So let's simply get rid of it.
Signed-off-by: David Hildenbrand
Message-Id: <20230713145551.2824980-2-da...@redhat.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_mem.c | 51 +++--
1 file changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 835f6cc2fb664..ed15d2a4bd96b 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -38,11 +38,6 @@ module_param(bbm_block_size, ulong, 0444);
MODULE_PARM_DESC(bbm_block_size,
"Big Block size in bytes. Default is 0 (auto-detection).");
-static bool bbm_safe_unplug = true;
-module_param(bbm_safe_unplug, bool, 0444);
-MODULE_PARM_DESC(bbm_safe_unplug,
-"Use a safe unplug mechanism in BBM, avoiding long/endless loops");
-
/*
* virtio-mem currently supports the following modes of operation:
*
@@ -2111,38 +2106,32 @@ static int
virtio_mem_bbm_offline_remove_and_unplug_bb(struct virtio_mem *vm,
VIRTIO_MEM_BBM_BB_ADDED))
return -EINVAL;
- if (bbm_safe_unplug) {
- /*
-* Start by fake-offlining all memory. Once we marked the device
-* block as fake-offline, all newly onlined memory will
-* automatically be kept fake-offline. Protect from concurrent
-* onlining/offlining until we have a consistent state.
-*/
- mutex_lock(&vm->hotplug_mutex);
- virtio_mem_bbm_set_bb_state(vm, bb_id,
- VIRTIO_MEM_BBM_BB_FAKE_OFFLINE);
+ /*
+* Start by fake-offlining all memory. Once we marked the device
+* block as fake-offline, all newly onlined memory will
+* automatically be kept fake-offline. Protect from concurrent
+* onlining/offlining until we have a consistent state.
+*/
+ mutex_lock(&vm->hotplug_mutex);
+ virtio_mem_bbm_set_bb_state(vm, bb_id, VIRTIO_MEM_BBM_BB_FAKE_OFFLINE);
- for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
- page = pfn_to_online_page(pfn);
- if (!page)
- continue;
+ for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ page = pfn_to_online_page(pfn);
+ if (!page)
+ continue;
- rc = virtio_mem_fake_offline(pfn, PAGES_PER_SECTION);
- if (rc) {
- end_pfn = pfn;
- goto rollback_safe_unplug;
- }
+ rc = virtio_mem_fake_offline(pfn, PAGES_PER_SECTION);
+ if (rc) {
+ end_pfn = pfn;
+ goto rollback;
}
- mutex_unlock(&vm->hotplug_mutex);
}
+ mutex_unlock(&vm->hotplug_mutex);
rc = virtio_mem_bbm_offline_and_remove_bb(vm, bb_id);
if (rc) {
- if (bbm_safe_unplug) {
- mutex_lock(&vm->hotplug_mutex);
- goto rollback_safe_unplug;
- }
- return rc;
+ mutex_lock(&vm->hotplug_mutex);
+ goto rollback;
}
rc = virtio_mem_bbm_unplug_bb(vm, bb_id);
@@ -2154,7 +2143,7 @@ static int
virtio_mem_bbm_offline_remove_and_unplug_bb(struct virtio_mem *vm,
VIRTIO_MEM_BBM_BB_UNUSED);
return rc;
-rollback_safe_unplug:
+rollback:
for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
page = pfn_to_online_page(pfn);
if (!p
[PATCH AUTOSEL 6.4 09/17] virtio-mem: check if the config changed before fake offlining memory
From: David Hildenbrand
[ Upstream commit f55484fd7be923b740e8e1fc304070ba53675cb4 ]
If we repeatedly fail to fake offline memory to unplug it, we won't be
sending any unplug requests to the device. However, we only check if the
config changed when sending such (un)plug requests.
We could end up trying for a long time to unplug memory, even though
the config changed already and we're not supposed to unplug memory
anymore. For example, the hypervisor might detect a low-memory situation
while unplugging memory and decide to replug some memory. Continuing
trying to unplug memory in that case can be problematic.
So let's check on a more regular basis.
Signed-off-by: David Hildenbrand
Message-Id: <20230713145551.2824980-5-da...@redhat.com>
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_mem.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index a5cf92e3e5af2..fa5226c198cc6 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -1189,7 +1189,8 @@ static void virtio_mem_fake_online(unsigned long pfn,
unsigned long nr_pages)
* Try to allocate a range, marking pages fake-offline, effectively
* fake-offlining them.
*/
-static int virtio_mem_fake_offline(unsigned long pfn, unsigned long nr_pages)
+static int virtio_mem_fake_offline(struct virtio_mem *vm, unsigned long pfn,
+ unsigned long nr_pages)
{
const bool is_movable = is_zone_movable_page(pfn_to_page(pfn));
int rc, retry_count;
@@ -1202,6 +1203,14 @@ static int virtio_mem_fake_offline(unsigned long pfn,
unsigned long nr_pages)
* some guarantees.
*/
for (retry_count = 0; retry_count < 5; retry_count++) {
+ /*
+* If the config changed, stop immediately and go back to the
+* main loop: avoid trying to keep unplugging if the device
+* might have decided to not remove any more memory.
+*/
+ if (atomic_read(&vm->config_changed))
+ return -EAGAIN;
+
rc = alloc_contig_range(pfn, pfn + nr_pages, MIGRATE_MOVABLE,
GFP_KERNEL);
if (rc == -ENOMEM)
@@ -1951,7 +1960,7 @@ static int virtio_mem_sbm_unplug_sb_online(struct
virtio_mem *vm,
start_pfn = PFN_DOWN(virtio_mem_mb_id_to_phys(mb_id) +
sb_id * vm->sbm.sb_size);
- rc = virtio_mem_fake_offline(start_pfn, nr_pages);
+ rc = virtio_mem_fake_offline(vm, start_pfn, nr_pages);
if (rc)
return rc;
@@ -2149,7 +2158,7 @@ static int
virtio_mem_bbm_offline_remove_and_unplug_bb(struct virtio_mem *vm,
if (!page)
continue;
- rc = virtio_mem_fake_offline(pfn, PAGES_PER_SECTION);
+ rc = virtio_mem_fake_offline(vm, pfn, PAGES_PER_SECTION);
if (rc) {
end_pfn = pfn;
goto rollback;
--
2.40.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.6 21/31] vsock: read from socket's error queue
From: Arseniy Krasnov
[ Upstream commit 49dbe25adac42d3e06f65d1420946bec65896222 ]
This adds handling of MSG_ERRQUEUE input flag in receive call. This flag
is used to read socket's error queue instead of data queue. Possible
scenario of error queue usage is receiving completions for transmission
with MSG_ZEROCOPY flag. This patch also adds new defines: 'SOL_VSOCK'
and 'VSOCK_RECVERR'.
Signed-off-by: Arseniy Krasnov
Reviewed-by: Stefano Garzarella
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
include/linux/socket.h | 1 +
include/uapi/linux/vm_sockets.h | 17 +
net/vmw_vsock/af_vsock.c| 6 ++
3 files changed, 24 insertions(+)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 39b74d83c7c4a..cfcb7e2c3813f 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -383,6 +383,7 @@ struct ucred {
#define SOL_MPTCP 284
#define SOL_MCTP 285
#define SOL_SMC286
+#define SOL_VSOCK 287
/* IPX options */
#define IPX_TYPE 1
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index c60ca33eac594..ed07181d4eff9 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -191,4 +191,21 @@ struct sockaddr_vm {
#define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9)
+/* MSG_ZEROCOPY notifications are encoded in the standard error format,
+ * sock_extended_err. See Documentation/networking/msg_zerocopy.rst in
+ * kernel source tree for more details.
+ */
+
+/* 'cmsg_level' field value of 'struct cmsghdr' for notification parsing
+ * when MSG_ZEROCOPY flag is used on transmissions.
+ */
+
+#define SOL_VSOCK 287
+
+/* 'cmsg_type' field value of 'struct cmsghdr' for notification parsing
+ * when MSG_ZEROCOPY flag is used on transmissions.
+ */
+
+#define VSOCK_RECVERR 1
+
#endif /* _UAPI_VM_SOCKETS_H */
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 020cf17ab7e47..ccd8cefeea7ba 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -89,6 +89,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -110,6 +111,7 @@
#include
#include
#include
+#include
static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr);
static void vsock_sk_destruct(struct sock *sk);
@@ -2134,6 +2136,10 @@ vsock_connectible_recvmsg(struct socket *sock, struct
msghdr *msg, size_t len,
int err;
sk = sock->sk;
+
+ if (unlikely(flags & MSG_ERRQUEUE))
+ return sock_recv_errqueue(sk, msg, len, SOL_VSOCK,
VSOCK_RECVERR);
+
vsk = vsock_sk(sk);
err = 0;
--
2.42.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.5 20/30] vsock: read from socket's error queue
From: Arseniy Krasnov
[ Upstream commit 49dbe25adac42d3e06f65d1420946bec65896222 ]
This adds handling of MSG_ERRQUEUE input flag in receive call. This flag
is used to read socket's error queue instead of data queue. Possible
scenario of error queue usage is receiving completions for transmission
with MSG_ZEROCOPY flag. This patch also adds new defines: 'SOL_VSOCK'
and 'VSOCK_RECVERR'.
Signed-off-by: Arseniy Krasnov
Reviewed-by: Stefano Garzarella
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
include/linux/socket.h | 1 +
include/uapi/linux/vm_sockets.h | 17 +
net/vmw_vsock/af_vsock.c| 6 ++
3 files changed, 24 insertions(+)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 39b74d83c7c4a..cfcb7e2c3813f 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -383,6 +383,7 @@ struct ucred {
#define SOL_MPTCP 284
#define SOL_MCTP 285
#define SOL_SMC286
+#define SOL_VSOCK 287
/* IPX options */
#define IPX_TYPE 1
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index c60ca33eac594..ed07181d4eff9 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -191,4 +191,21 @@ struct sockaddr_vm {
#define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9)
+/* MSG_ZEROCOPY notifications are encoded in the standard error format,
+ * sock_extended_err. See Documentation/networking/msg_zerocopy.rst in
+ * kernel source tree for more details.
+ */
+
+/* 'cmsg_level' field value of 'struct cmsghdr' for notification parsing
+ * when MSG_ZEROCOPY flag is used on transmissions.
+ */
+
+#define SOL_VSOCK 287
+
+/* 'cmsg_type' field value of 'struct cmsghdr' for notification parsing
+ * when MSG_ZEROCOPY flag is used on transmissions.
+ */
+
+#define VSOCK_RECVERR 1
+
#endif /* _UAPI_VM_SOCKETS_H */
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 020cf17ab7e47..ccd8cefeea7ba 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -89,6 +89,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -110,6 +111,7 @@
#include
#include
#include
+#include
static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr);
static void vsock_sk_destruct(struct sock *sk);
@@ -2134,6 +2136,10 @@ vsock_connectible_recvmsg(struct socket *sock, struct
msghdr *msg, size_t len,
int err;
sk = sock->sk;
+
+ if (unlikely(flags & MSG_ERRQUEUE))
+ return sock_recv_errqueue(sk, msg, len, SOL_VSOCK,
VSOCK_RECVERR);
+
vsk = vsock_sk(sk);
err = 0;
--
2.42.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 6.1 11/18] vsock: read from socket's error queue
From: Arseniy Krasnov
[ Upstream commit 49dbe25adac42d3e06f65d1420946bec65896222 ]
This adds handling of MSG_ERRQUEUE input flag in receive call. This flag
is used to read socket's error queue instead of data queue. Possible
scenario of error queue usage is receiving completions for transmission
with MSG_ZEROCOPY flag. This patch also adds new defines: 'SOL_VSOCK'
and 'VSOCK_RECVERR'.
Signed-off-by: Arseniy Krasnov
Reviewed-by: Stefano Garzarella
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
include/linux/socket.h | 1 +
include/uapi/linux/vm_sockets.h | 17 +
net/vmw_vsock/af_vsock.c| 6 ++
3 files changed, 24 insertions(+)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index de3701a2a2129..1db29aab8f9c3 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -376,6 +376,7 @@ struct ucred {
#define SOL_MPTCP 284
#define SOL_MCTP 285
#define SOL_SMC286
+#define SOL_VSOCK 287
/* IPX options */
#define IPX_TYPE 1
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index c60ca33eac594..ed07181d4eff9 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -191,4 +191,21 @@ struct sockaddr_vm {
#define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9)
+/* MSG_ZEROCOPY notifications are encoded in the standard error format,
+ * sock_extended_err. See Documentation/networking/msg_zerocopy.rst in
+ * kernel source tree for more details.
+ */
+
+/* 'cmsg_level' field value of 'struct cmsghdr' for notification parsing
+ * when MSG_ZEROCOPY flag is used on transmissions.
+ */
+
+#define SOL_VSOCK 287
+
+/* 'cmsg_type' field value of 'struct cmsghdr' for notification parsing
+ * when MSG_ZEROCOPY flag is used on transmissions.
+ */
+
+#define VSOCK_RECVERR 1
+
#endif /* _UAPI_VM_SOCKETS_H */
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 8360c790a8a01..84471745c0829 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -89,6 +89,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -110,6 +111,7 @@
#include
#include
#include
+#include
static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr);
static void vsock_sk_destruct(struct sock *sk);
@@ -2096,6 +2098,10 @@ vsock_connectible_recvmsg(struct socket *sock, struct
msghdr *msg, size_t len,
int err;
sk = sock->sk;
+
+ if (unlikely(flags & MSG_ERRQUEUE))
+ return sock_recv_errqueue(sk, msg, len, SOL_VSOCK,
VSOCK_RECVERR);
+
vsk = vsock_sk(sk);
err = 0;
--
2.42.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
Hi George, On Mon, Nov 5, 2012 at 1:00 PM, George Zhang wrote: > For additional information about the use of VMCI and in particular > VMCI Sockets, please refer to the VMCI Socket Programming Guide > available at https://www.vmware.com/support/developer/vmci-sdk/. Is there documentation about the protocol itself? I couldn't find it on the link above. Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
On 11/05/2012 01:32 PM, George Zhang wrote: > Sasha, > There is a 'brief' implementation notes aboutVSOCK protocol family > in af_vsock.c. More about user space layer socket programming is from > VMCI Socket Programming Guide. (remove crosst...@vmware.com for email > bouncing). > thanks, > George So all the documentation I see in the VMCI Socket Programming Guide is about userspace programming, and the documentation in af_vsock.c is all around implementation considerations. Is there anything that documents the actual protocol? Just for example, whats the deal with REQUEST/REQUEST2? it appears like something to deal with legacy code, but I'd really like to have it documented somewhere instead of trying to figure how everything works by looking at the code. Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 4/7] mm: introduce compaction and migration for ballooned pages
Hi guys, On 11/11/2012 02:01 PM, Rafael Aquini wrote: > Memory fragmentation introduced by ballooning might reduce significantly > the number of 2MB contiguous memory blocks that can be used within a guest, > thus imposing performance penalties associated with the reduced number of > transparent huge pages that could be used by the guest workload. > > This patch introduces the helper functions as well as the necessary changes > to teach compaction and migration bits how to cope with pages which are > part of a guest memory balloon, in order to make them movable by memory > compaction procedures. > > Signed-off-by: Rafael Aquini > Acked-by: Mel Gorman > --- I'm getting the following while fuzzing using trinity inside a KVM tools guest, on latest -next: [ 1642.783728] BUG: unable to handle kernel NULL pointer dereference at 0194 [ 1642.785083] IP: [] isolate_migratepages_range+0x344/0x7b0 [ 1642.786061] PGD 39e80067 PUD 39f6d067 PMD 0 [ 1642.786766] Oops: [#3] PREEMPT SMP DEBUG_PAGEALLOC [ 1642.787587] CPU 0 [ 1642.787884] Pid: 8522, comm: trinity-child5 Tainted: G D W 3.7.0-rc5-next-20121115-sasha-00013-g37271d3 #154 [ 1642.789483] RIP: 0010:[] [] isolate_migratepages_range+0x344/0x7b0 [ 1642.790016] RSP: 0018:880039d998d8 EFLAGS: 00010202 [ 1642.790016] RAX: 0054 RBX: eafd5480 RCX: 01fa [ 1642.790016] RDX: 80490049 RSI: 0004 RDI: 880039d99a20 [ 1642.790016] RBP: 880039d99978 R08: 0001 R09: [ 1642.790016] R10: 88003bfcefc0 R11: 0001 R12: 0003f552 [ 1642.790016] R13: 0153 R14: R15: 88004ffd2000 [ 1642.790016] FS: 7ff799de5700() GS:88001360() knlGS: [ 1642.790016] CS: 0010 DS: ES: CR0: 80050033 [ 1642.790016] CR2: 0194 CR3: 369ef000 CR4: 000406f0 [ 1642.790016] DR0: DR1: DR2: [ 1642.790016] DR3: DR6: 0ff0 DR7: 0400 [ 1642.790016] Process trinity-child5 (pid: 8522, threadinfo 880039d98000, task 8800298e8000) [ 1642.790016] Stack: [ 1642.790016] 01fa 880039d99a78 8800298e8000 880039d99a30 [ 1642.790016] 880039d99fd8 [ 1642.790016] 880039d99a20 eafd 880039d99a60 0003f600 [ 1642.790016] Call Trace: [ 1642.790016] [] ? isolate_freepages+0x1f0/0x1f0 [ 1642.790016] [] compact_zone+0x3ce/0x490 [ 1642.790016] [] ? __lock_acquired+0x3b/0x360 [ 1642.790016] [] compact_zone_order+0xde/0x120 [ 1642.790016] [] ? do_raw_spin_unlock+0xc8/0xe0 [ 1642.790016] [] try_to_compact_pages+0xbe/0x110 [ 1642.790016] [] __alloc_pages_direct_compact+0xba/0x206 [ 1642.790016] [] ? on_each_cpu_mask+0xd9/0x110 [ 1642.790016] [] __alloc_pages_nodemask+0x92f/0xbc0 [ 1642.790016] [] alloc_pages_vma+0xfc/0x150 [ 1642.790016] [] do_huge_pmd_anonymous_page+0x191/0x2b0 [ 1642.790016] [] ? __rcu_read_unlock+0x44/0xb0 [ 1642.790016] [] handle_mm_fault+0x1c9/0x350 [ 1642.790016] [] __get_user_pages+0x418/0x5f0 [ 1642.790016] [] ? do_mlock_pages+0x8c/0x160 [ 1642.790016] [] __mlock_vma_pages_range+0xb3/0xc0 [ 1642.790016] [] do_mlock_pages+0xe9/0x160 [ 1642.790016] [] sys_mlockall+0x160/0x1a0 [ 1642.790016] [] tracesys+0xe1/0xe6 [ 1642.790016] Code: a9 00 00 01 00 0f 85 6c 02 00 00 48 8b 43 08 a8 01 0f 85 60 02 00 00 8b 53 18 85 d2 0f 89 55 02 00 00 48 85 c0 0f 84 4c 02 00 00 <48> 8b 80 40 01 00 00 a9 00 00 00 20 0f 84 3a 02 00 00 45 84 f6 [ 1642.790016] RIP [] isolate_migratepages_range+0x344/0x7b0 [ 1642.790016] RSP [ 1642.790016] CR2: 0194 [ 1643.398013] ---[ end trace 0ad6459aa62f5d72 ]--- My guess is that we see those because of a race during the check in isolate_migratepages_range(). Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 4/7] mm: introduce compaction and migration for ballooned pages
On 11/20/2012 09:14 AM, Rafael Aquini wrote:
> On Sun, Nov 18, 2012 at 09:59:47AM -0500, Sasha Levin wrote:
>> On Sat, Nov 17, 2012 at 4:54 PM, Rafael Aquini wrote:
>>> On Sat, Nov 17, 2012 at 01:01:30PM -0500, Sasha Levin wrote:
>>>>
>>>> I'm getting the following while fuzzing using trinity inside a KVM tools
>>>> guest,
>>>> on latest -next:
>>>>
>>>> [ 1642.783728] BUG: unable to handle kernel NULL pointer dereference at
>>>> 0194
>>>> [ 1642.785083] IP: []
>>>> isolate_migratepages_range+0x344/0x7b0
>>>>
>>>> My guess is that we see those because of a race during the check in
>>>> isolate_migratepages_range().
>>>>
>>>>
>>>> Thanks,
>>>> Sasha
>>>
>>> Sasha, could you share your .config and steps you did used with trinity? So
>>> I
>>> can attempt to reproduce this issue you reported.
>>
>> Basically try running trinity (with ./trinity -m --quiet --dangerous
>> -l off) inside a disposable guest as root.
>>
>> I manage to hit that every couple of hours.
>>
>> Config attached.
>>
>
> Howdy Sasha,
>
> After several hours since last Sunday running trinity tests on a traditional
> KVM-QEMU guest as well as running it on a lkvm guest (both running
> next-20121115) I couldn't hit a single time the crash you've reported,
> (un)fortunately.
Odd... I can see it happening here every couple of hours.
> Also, the .config you gave me, applied on top of next-20121115, haven't
> produced
> the same bin you've running and hitting the mentioned bug, apparently.
>
> Here's the RIP for your crash:
> [ 1642.783728] BUG: unable to handle kernel NULL pointer dereference at
> 0194
> [ 1642.785083] IP: [] isolate_migratepages_range+0x344/0x7b0
>
>
> And here's the symbol address for the next-20121115 with your .config I've
> been
> running tests on:
> [raquini@x61 linux]$ nm -n vmlinux | grep isolate_migratepages_range
> 8122d890 T isolate_migratepages_range
>
> Also, it seems quite clear I'm missing something from your tree, as applying
> the
> RIP displacement (0x344) to my local isolate_migratepages_range sym addr leads
> me to the _middle_ of a instruction opcode that does not dereference any
> pointers at all.
Yup, I carry another small fix to mpol (which is unrelated to this one).
> So, if you're consistently reproducing the same crash, consider to share with
> us
> a disassembled dump from the isolate_migratepages_range() you're running along
> with the crash stack-dump, please.
Sure!
The call chain is:
isolate_migratepages_range
balloon_page_movable
__is_movable_balloon_page
mapping_balloon
mapping_balloon() fails because it checks for mapping to be non-null (and it is
-
it's usually a small value like 0x50), and then it dereferences that.
The relevant assembly is:
static inline int mapping_balloon(struct address_space *mapping)
{
return mapping && test_bit(AS_BALLOON_MAP, &mapping->flags);
17ab: 48 85 c0test %rax,%rax
17ae: 0f 84 4c 02 00 00 je 1a00
17b4: 48 8b 80 40 01 00 00mov0x140(%rax),%rax
17bb: a9 00 00 00 20 test $0x2000,%eax
17c0: 0f 84 3a 02 00 00 je 1a00
It dies on 17b4.
Let me know if you need anything else from me, I can also add debug code into
the
kernel if it would help you...
Thanks,
Sasha
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 4/7] mm: introduce compaction and migration for ballooned pages
On 11/21/2012 07:01 PM, Rafael Aquini wrote:
> On Tue, Nov 20, 2012 at 08:18:04PM -0500, Sasha Levin wrote:
>> On 11/20/2012 09:14 AM, Rafael Aquini wrote:
>>> On Sun, Nov 18, 2012 at 09:59:47AM -0500, Sasha Levin wrote:
>>>> On Sat, Nov 17, 2012 at 4:54 PM, Rafael Aquini wrote:
>>>>> On Sat, Nov 17, 2012 at 01:01:30PM -0500, Sasha Levin wrote:
>>>>>>
>>>>>> I'm getting the following while fuzzing using trinity inside a KVM tools
>>>>>> guest,
>>>>>> on latest -next:
>>>>>>
>>>>>> [ 1642.783728] BUG: unable to handle kernel NULL pointer dereference at
>>>>>> 0194
>>>>>> [ 1642.785083] IP: []
>>>>>> isolate_migratepages_range+0x344/0x7b0
>>>>>>
>>>>>> My guess is that we see those because of a race during the check in
>>>>>> isolate_migratepages_range().
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Sasha
>>>>>
>>>>> Sasha, could you share your .config and steps you did used with trinity?
>>>>> So I
>>>>> can attempt to reproduce this issue you reported.
>>>>
>>>> Basically try running trinity (with ./trinity -m --quiet --dangerous
>>>> -l off) inside a disposable guest as root.
>>>>
>>>> I manage to hit that every couple of hours.
>>>>
>>>> Config attached.
>>>>
>>>
>>> Howdy Sasha,
>>>
>>> After several hours since last Sunday running trinity tests on a traditional
>>> KVM-QEMU guest as well as running it on a lkvm guest (both running
>>> next-20121115) I couldn't hit a single time the crash you've reported,
>>> (un)fortunately.
>>
>> Odd... I can see it happening here every couple of hours.
>>
>>> Also, the .config you gave me, applied on top of next-20121115, haven't
>>> produced
>>> the same bin you've running and hitting the mentioned bug, apparently.
>>>
>>> Here's the RIP for your crash:
>>> [ 1642.783728] BUG: unable to handle kernel NULL pointer dereference at
>>> 0194
>>> [ 1642.785083] IP: []
>>> isolate_migratepages_range+0x344/0x7b0
>>>
>>>
>>> And here's the symbol address for the next-20121115 with your .config I've
>>> been
>>> running tests on:
>>> [raquini@x61 linux]$ nm -n vmlinux | grep isolate_migratepages_range
>>> 8122d890 T isolate_migratepages_range
>>>
>>> Also, it seems quite clear I'm missing something from your tree, as
>>> applying the
>>> RIP displacement (0x344) to my local isolate_migratepages_range sym addr
>>> leads
>>> me to the _middle_ of a instruction opcode that does not dereference any
>>> pointers at all.
>>
>> Yup, I carry another small fix to mpol (which is unrelated to this one).
>>
>>> So, if you're consistently reproducing the same crash, consider to share
>>> with us
>>> a disassembled dump from the isolate_migratepages_range() you're running
>>> along
>>> with the crash stack-dump, please.
>>
>> Sure!
>>
>> The call chain is:
>>
>> isolate_migratepages_range
>> balloon_page_movable
>> __is_movable_balloon_page
>> mapping_balloon
>>
>> mapping_balloon() fails because it checks for mapping to be non-null (and it
>> is -
>> it's usually a small value like 0x50), and then it dereferences that.
>>
>> The relevant assembly is:
>>
>> static inline int mapping_balloon(struct address_space *mapping)
>> {
>> return mapping && test_bit(AS_BALLOON_MAP, &mapping->flags);
>> 17ab: 48 85 c0test %rax,%rax
>> 17ae: 0f 84 4c 02 00 00 je 1a00
>>
>> 17b4: 48 8b 80 40 01 00 00mov0x140(%rax),%rax
>> 17bb: a9 00 00 00 20 test $0x2000,%eax
>> 17c0: 0f 84 3a 02 00 00 je 1a00
>>
>>
>> It dies on 17b4.
>>
>> Let me know if you need anything else from me, I can also add debug code
>> into the
>> kernel if it would help you...
>>
>
> I still failing miserably on getting a reproducer, but I'm quite curious about
> what kind of page is being left behind with
Re: [PATCH v12 4/7] mm: introduce compaction and migration for ballooned pages
On Thu, Nov 22, 2012 at 10:10 AM, Rafael Aquini wrote: > On Thu, Nov 22, 2012 at 09:19:15AM -0500, Sasha Levin wrote: >> And managed to reproduce it only once through last night, here is the dump I >> got >> before the oops: >> >> [ 2760.356820] page:ead00e00 count:1 mapcount:-2147287036 >> mapping:04f4 index:0xd00e0003 >> [ 2760.362354] page flags: 0x3501800(private|private_2) >> > > Thanks alot for following up this one Sasha. > > > We're stumbling across a private page -- seems something in your setup is > doing > this particular usage, and that's probably why I'm not seeing the same here. > > Regardless being a particular case or not, we shouldn't be poking at that > private page, so I figured the tests I'm doing at balloon_page_movable() are > incomplete and dumb. > > Perhaps, a better way to proceed here would be assuring the NR_PAGEFLAGS > rightmost bits from page->flags are all cleared, as this is the state a page > coming from buddy to the balloon list will be, and this is the state the > balloon > page flags will be kept as long as it lives as such (we don't play with any > flag > at balloon level). > > > Here goes what I'll propose after you confirm it doesn't trigger your crash > anymore, as it simplifies the code and reduces the testing battery @ > balloon_page_movable() -- ballooned pages have no flags set, 1 refcount and 0 > mapcount, always. > > > Could you give this a try? > > Thank you! Ran it for a while, no more BUGs, yay :) Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] virtio_console: correct error message on failure of debugfs_create_dir
debugfs_create_dir() returns NULL if it fails, there's little point in
calling PTR_ERR on it.
Signed-off-by: Sasha Levin
---
drivers/char/virtio_console.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index c594cb1..490b70e 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -2212,10 +2212,9 @@ static int __init init(void)
}
pdrvdata.debugfs_dir = debugfs_create_dir("virtio-ports", NULL);
- if (!pdrvdata.debugfs_dir) {
- pr_warning("Error %ld creating debugfs dir for virtio-ports\n",
- PTR_ERR(pdrvdata.debugfs_dir));
- }
+ if (!pdrvdata.debugfs_dir)
+ pr_warn("Error creating debugfs dir for virtio-ports\n");
+
INIT_LIST_HEAD(&pdrvdata.consoles);
INIT_LIST_HEAD(&pdrvdata.portdevs);
--
1.8.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: correct error message on failure of debugfs_create_dir
On Mon, Dec 24, 2012 at 12:39 PM, Greg Kroah-Hartman wrote: > On Mon, Dec 24, 2012 at 11:55:46AM +, Arnd Bergmann wrote: >> On Friday 21 December 2012, Amit Shah wrote: >> > On (Thu) 20 Dec 2012 [14:11:21], Sasha Levin wrote: >> > > debugfs_create_dir() returns NULL if it fails, there's little point in >> > > calling PTR_ERR on it. >> > >> > debugfs_create_dir() does return an error value if debugfs is not >> > enabled. >> > >> > This check for !pdrvdata.debugfs_dir should infact use >> > IS_ERR_OR_NULL(). Care to submit a patch for that? >> >> How about we fix the stub instead to return NULL when debugfs is disabled? > > No, please read debugfs.h for why I decided to not do this (i.e. we try > to learn from our mistakes...) Why won't we fix it the other way around and return an actual error code instead of a NULL on failure? Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
Hi Andy, On Wed, Feb 6, 2013 at 7:23 PM, Andy King wrote: > + * Specifically, we initialize the vsock_bind_table array to a size of > + * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through > + * vsock_bind_table[VSOCK_HASH_SIZE - 1] are for bound sockets and > + * vsock_bind_table[VSOCK_HASH_SIZE] is for unbound sockets. The hash > function > + * mods with VSOCK_HASH_SIZE - 1 to ensure this. > + */ > +#define VSOCK_HASH_SIZE 251 > +#define MAX_PORT_RETRIES24 > + > +#define VSOCK_HASH(addr)((addr)->svm_port % (VSOCK_HASH_SIZE - 1)) > +#define vsock_bound_sockets(addr) (&vsock_bind_table[VSOCK_HASH(addr)]) > +#define vsock_unbound_sockets (&vsock_bind_table[VSOCK_HASH_SIZE]) > + > +/* XXX This can probably be implemented in a better way. */ > +#define VSOCK_CONN_HASH(src, dst) \ > + (((src)->svm_cid ^ (dst)->svm_port) % (VSOCK_HASH_SIZE - 1)) > +#define vsock_connected_sockets(src, dst) \ > + (&vsock_connected_table[VSOCK_CONN_HASH(src, dst)]) > +#define vsock_connected_sockets_vsk(vsk) \ > + vsock_connected_sockets(&(vsk)->remote_addr, &(vsk)->local_addr) > + > +static struct list_head vsock_bind_table[VSOCK_HASH_SIZE + 1]; > +static struct list_head vsock_connected_table[VSOCK_HASH_SIZE]; > +static DEFINE_SPINLOCK(vsock_table_lock); Why isn't it using the kernel's linux/hashtable.h? Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] virtio-spec: document virtio-9p
Add basic documentation for virtio-9p. I can expand more on device operation,
but I don't think there's anything significant enough for the spec to be
mentioned there. Please let me know if I'm wrong.
Signed-off-by: Sasha Levin
---
virtio-spec.lyx | 206
1 file changed, 206 insertions(+)
diff --git a/virtio-spec.lyx b/virtio-spec.lyx
index c23a345..73a0567 100644
--- a/virtio-spec.lyx
+++ b/virtio-spec.lyx
@@ -57,6 +57,7 @@
\html_css_as_file 0
\html_be_strict false
\author -1930653948 "Amos Kong"
+\author -1728740334 "Sasha Levin" sasha.le...@oracle.com
\author -875410574 "Pawel Moll"
\author -608949062 "Rusty Russell,,,"
\author -385801441 "Cornelia Huck" cornelia.h...@de.ibm.com
@@ -619,7 +620,13 @@ Appendix I
\begin_inset Text
\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365526571
+Appendix J
+\change_deleted -1728740334 1365526568
-
+\change_unchanged
+
\end_layout
\end_inset
@@ -9678,6 +9685,204 @@ For MMC devices (inquiry type 5) there would be some
overlap between this
\end_layout
\end_deeper
+\end_deeper
+\begin_layout Chapter*
+
+\change_inserted -1728740334 1365526640
+Appendix J: 9p Transport
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted -1728740334 1365526873
+The virtio transport for 9p provides an interface to transfer 9p messages
+ between the device and the driver.
+\end_layout
+
+\begin_layout Section*
+
+\change_inserted -1728740334 1365526612
+Configuration
+\end_layout
+
+\begin_layout Description
+
+\change_inserted -1728740334 1365526876
+Subsystem
+\begin_inset space ~
+\end_inset
+
+Device
+\begin_inset space ~
+\end_inset
+
+ID 9
+\end_layout
+
+\begin_layout Description
+
+\change_inserted -1728740334 1365526891
+Virtqueues 0:requests.
+\end_layout
+
+\begin_layout Description
+
+\change_inserted -1728740334 1365527214
+Feature
+\begin_inset space ~
+\end_inset
+
+bits
+\end_layout
+
+\begin_deeper
+\begin_layout Description
+
+\change_inserted -1728740334 1365529363
+VIRTIO_9P_MOUNT_TAG(0) The mount point is specified in the device
configuration.
+\end_layout
+
+\end_deeper
+\begin_layout Description
+
+\change_inserted -1728740334 1365527300
+Device
+\begin_inset space ~
+\end_inset
+
+configuration
+\begin_inset space ~
+\end_inset
+
+layout Both fields of this configuration are available only if
VIRTIO_9P_MOUNT_T
+AG was negotiated:
+\begin_inset listings
+inline false
+status open
+
+\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365527046
+
+struct virtio_9p_config {
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365527050
+
+ /* length of the tag name */
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365527055
+
+ __u16 tag_len;
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365527056
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365527065
+
+ /* non-NULL terminated tag name */
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365527072
+
+ __u8 tag[0];
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted -1728740334 1365527072
+
+} __attribute__((packed));
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_deeper
+\begin_layout Description
+
+\change_inserted -1728740334 1365527670
+tag_len is the length of the mount tag string.
+\end_layout
+
+\begin_layout Description
+
+\change_inserted -1728740334 1365527700
+tag is the name of the moung tag.
+ The tag should not be terminated by NULL.
+\end_layout
+
+\end_deeper
+\begin_layout Section*
+
+\change_inserted -1728740334 1365526612
+Device Initialization
+\end_layout
+
+\begin_layout Enumerate
+
+\change_inserted -1728740334 1365527786
+The requests virtqueue is initialized.
+\end_layout
+
+\begin_layout Enumerate
+
+\change_inserted -1728740334 1365527828
+If VIRTIO_9P_MOUNT_TAG was negotiated:
+\end_layout
+
+\begin_deeper
+\begin_layout Enumerate
+
+\change_inserted -1728740334 1365527872
+the tag_len field is read from the configuration to acertain the length
+ of the mount tag.
+\end_layout
+
+\begin_layout Enumerate
+
+\change_inserted -1728740334 1365527876
+tag_len bytes are read from the tag field and are used as the name of the
+ mount tag.
+\end_layout
+
+\end_deeper
+\begin_layout Enumerate
+
+\change_inserted -1728740334 1365527948
+The device is now ready to process requests.
+\end_layout
+
+\begin_layout Section*
+
+\change_inserted -1728740334 1365526612
+Device Operation
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted -1728740334 1365529176
+When the driver wantes to send a 9P request it places the descriptor of
+ the PDU in the queue.
+ It will be processed by the device according to the 9P protocol specifications
+ (available at http://ericvh.github.io/9p-rfc/) and returned to the driver.
+\end_layout
+
\begin_
Re: [RFC 0/5] Introduce VM Sockets virtio transport
Hi Asias,
Looks nice! Some comments inline below (I've removed anything that mst already
commented on).
On 06/27/2013 03:59 AM, Asias He wrote:
Hello guys,
In commit d021c344051af91 (VSOCK: Introduce VM Sockets), VMware added VM
Sockets support. VM Sockets allows communication between virtual
machines and the hypervisor. VM Sockets is able to use different
hyervisor neutral transport to transfer data. Currently, only VMware
VMCI transport is supported.
This series introduces virtio transport for VM Sockets.
Any comments are appreciated! Thanks!
Code:
=
1) kernel bits
git://github.com/asias/linux.git vsock
2) userspace bits:
git://github.com/asias/linux-kvm.git vsock
Howto:
=
Make sure you have these kernel options:
CONFIG_VSOCKETS=y
CONFIG_VIRTIO_VSOCKETS=y
CONFIG_VIRTIO_VSOCKETS_COMMON=y
CONFIG_VHOST_VSOCK=m
$ git clone git://github.com/asias/linux-kvm.git
$ cd linux-kvm/tools/kvm
$ co -b vsock origin/vsock
$ make
$ modprobe vhost_vsock
$ ./lkvm run -d os.img -k bzImage --vsock guest_cid
Test:
=
I hacked busybox's http server and wget to run over vsock. Start http
server in host and guest, download a 512MB file in guest and host
simultaneously for 6000 times. Manged to run the http stress test.
Also, I wrote a small libvsock.so to play the LD_PRELOAD trick and
managed to make sshd and ssh work over virito-vsock without modifying
the source code.
Why did it require hacking in the first place? Does running with kvmtool
and just doing regular networking over virtio-net running on top of vsock
achieves the same goal?
Draft VM Sockets Virtio Device spec:
=
Appendix K: VM Sockets Device
The virtio VM sockets device is a virtio transport device for VM Sockets. VM
Sockets allows communication between virtual machines and the hypervisor.
Configuration:
Subsystem Device ID 13
Virtqueues:
0:controlq; 1:receiveq0; 2:transmitq0 ... 2N+1:receivqN; 2N+2:transmitqN
controlq is "defined but not used", is there something in mind for it? if not,
does it make sense keeping it here? we can always re-add it to the end just
like in virtio-net.
Feature bits:
Currently, no feature bits are defined.
Device configuration layout:
Two configuration fields are currently defined.
struct virtio_vsock_config {
__u32 guest_cid;
__u32 max_virtqueue_pairs;
} __packed;
The guest_cid field specifies the guest context id which likes the guest IP
address. The max_virtqueue_pairs field specifies the maximum number of receive
and transmit virtqueue pairs (receiveq0 ... receiveqN and transmitq0 ...
transmitqN respectively; N = max_virtqueue_pairs - 1 ) that can be configured.
The driver is free to use only one virtqueue pairs, or it can use more to
achieve better performance.
How does the driver tell the device how many vqs it's planning on actually
using?
or is it assumed that all of them are in use?
Device Initialization:
The initialization routine should discover the device's virtqueues.
Device Operation:
Packets are transmitted by placing them in the transmitq0..transmitqN, and
buffers for incoming packets are placed in the receiveq0..receiveqN. In each
case, the packet itself is preceded by a header:
struct virtio_vsock_hdr {
__u32 src_cid;
__u32 src_port;
__u32 dst_cid;
__u32 dst_port;
__u32 len;
__u8type;
__u8op;
__u8shut;
__u64 fwd_cnt;
__u64 buf_alloc;
} __packed;
src_cid and dst_cid: specify the source and destination context id.
src_port and dst_port: specify the source and destination port.
len: specifies the size of the data payload, it could be zero if no data
payload is transferred.
type: specifies the type of the packet, it can be SOCK_STREAM or SOCK_DGRAM.
op: specifies the operation of the packet, it is defined as follows.
enum {
VIRTIO_VSOCK_OP_INVALID = 0,
VIRTIO_VSOCK_OP_REQUEST = 1,
VIRTIO_VSOCK_OP_NEGOTIATE = 2,
VIRTIO_VSOCK_OP_OFFER = 3,
VIRTIO_VSOCK_OP_ATTACH = 4,
VIRTIO_VSOCK_OP_RW = 5,
VIRTIO_VSOCK_OP_CREDIT = 6,
VIRTIO_VSOCK_OP_RST = 7,
VIRTIO_VSOCK_OP_SHUTDOWN = 8,
};
shut: specifies the shutdown mode when the socket is being shutdown. 1 is for
receive shutdown, 2 is for transmit shutdown, 3 is for both receive and transmit
shutdown.
fwd_cnt: specifies the the number of bytes the receiver has forwarded to
userspace.
For the previous packet? For the entire session? Reading ahead makes it clear
but
it's worth mentioning here the context just to make it easy for implementers.
buf_alloc: specifies the size of the receiver's recieve buffer in bytes.
receive
Virtio VM socket connection creation:
1) Client
[PATCH AUTOSEL 5.14 34/40] scsi: virtio_scsi: Fix spelling mistake "Unsupport" -> "Unsupported"
From: Colin Ian King
[ Upstream commit cced4c0ec7c06f5230a2958907a409c849762293 ]
There are a couple of spelling mistakes in pr_info and pr_err messages.
Fix them.
Link: https://lore.kernel.org/r/20210924230330.143785-1-colin.k...@canonical.com
Signed-off-by: Colin Ian King
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/virtio_scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index b0deaf4af5a3..13f55f41a902 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -300,7 +300,7 @@ static void virtscsi_handle_transport_reset(struct
virtio_scsi *vscsi,
}
break;
default:
- pr_info("Unsupport virtio scsi event reason %x\n",
event->reason);
+ pr_info("Unsupported virtio scsi event reason %x\n",
event->reason);
}
}
@@ -392,7 +392,7 @@ static void virtscsi_handle_event(struct work_struct *work)
virtscsi_handle_param_change(vscsi, event);
break;
default:
- pr_err("Unsupport virtio scsi event %x\n", event->event);
+ pr_err("Unsupported virtio scsi event %x\n", event->event);
}
virtscsi_kick_event(vscsi, event_node);
}
--
2.33.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 1/3] MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface
On Thu, Nov 11, 2021 at 11:40:02AM -0800, Srivatsa S. Bhat wrote: On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote: On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote: > On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote: > > On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote: > > > From: Srivatsa S. Bhat (VMware) > > > > > > Deep has decided to transfer maintainership of the VMware hypervisor > > > interface to Srivatsa, and the joint-maintainership of paravirt ops in > > > the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file > > > to reflect this change. > > > > > > Signed-off-by: Srivatsa S. Bhat (VMware) > > > Acked-by: Alexey Makhalov > > > Acked-by: Deep Shah > > > Acked-by: Juergen Gross > > > Cc: sta...@vger.kernel.org > > > > Why are MAINTAINERS updates needed for stable? That's not normal :( > > So that people posting bug-fixes / backports to these subsystems for > older kernels (stable and LTS releases) will CC the new subsystem > maintainers. That's not how stable releases work at all. > That's why I added CC stable tag only to the first two > patches which add/replace maintainers and not the third patch which is > just a cleanup. Patches for stable kernels need to go into Linus's tree first, and if you have the MAINTAINERS file updated properly there, then you will be properly cc:ed. We do not look at the MAINTAINERS file for the older kernel when sending patches out, it's totally ignored as that was the snapshot at a point in time, which is usually no longer the true state. Sure, but that's the case for patches that get mainlined (and subsequently backported to -stable) /after/ this update to the MAINTAINERS file gets merged into mainline. When adding the CC stable tag, the case I was trying to address was for patches that are already in mainline but weren't CC'ed to stable, and at some later point, somebody decides to backport them to older stable kernels. In that case, there is a chance that the contributor might run ./get_maintainer.pl against the stable tree (as that's the tree they are backporting the upstream commit against) and end up not CC'ing the new maintainers. So, I thought it would be good to keep the maintainer info updated in the older stable kernels too. If you look at cases like these, I can see an argument around bringing it back to -stable. However, changes in the upstream MAINTAINERS file aren't limited to just change in maintainers. How would we handle addition of maintainers of a new code upstream? Or removal of maintainers due to code deletion? Or code movement upstream that isn't reflected in the stable tree (think a driver graduating from staging). It becomes a mess quite quickly and the easiest solution here is to just use upstream's MAINTAINERS file. Maybe we should just remove MAINTAINERS from stable trees to make it obvious. -- Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 08/65] drm/virtio: fix the missed drm_gem_object_put() in virtio_gpu_user_framebuffer_create()
From: Jing Xiangfeng
[ Upstream commit a63f393dd7e1ebee707c9dee1d197fdc33d6486b ]
virtio_gpu_user_framebuffer_create() misses to call drm_gem_object_put()
in an error path. Add the missed function call to fix it.
Signed-off-by: Jing Xiangfeng
Link:
http://patchwork.freedesktop.org/patch/msgid/1633770560-11658-1-git-send-email-jingxiangf...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index a6caebd4a0dd6..5b00310ac4cd4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -308,8 +308,10 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
virtio_gpu_fb = kzalloc(sizeof(*virtio_gpu_fb), GFP_KERNEL);
- if (virtio_gpu_fb == NULL)
+ if (virtio_gpu_fb == NULL) {
+ drm_gem_object_put(obj);
return ERR_PTR(-ENOMEM);
+ }
ret = virtio_gpu_framebuffer_init(dev, virtio_gpu_fb, mode_cmd, obj);
if (ret) {
--
2.33.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 08/65] drm/virtio: fix the missed drm_gem_object_put() in virtio_gpu_user_framebuffer_create()
From: Jing Xiangfeng
[ Upstream commit a63f393dd7e1ebee707c9dee1d197fdc33d6486b ]
virtio_gpu_user_framebuffer_create() misses to call drm_gem_object_put()
in an error path. Add the missed function call to fix it.
Signed-off-by: Jing Xiangfeng
Link:
http://patchwork.freedesktop.org/patch/msgid/1633770560-11658-1-git-send-email-jingxiangf...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index a6caebd4a0dd6..5b00310ac4cd4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -308,8 +308,10 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
virtio_gpu_fb = kzalloc(sizeof(*virtio_gpu_fb), GFP_KERNEL);
- if (virtio_gpu_fb == NULL)
+ if (virtio_gpu_fb == NULL) {
+ drm_gem_object_put(obj);
return ERR_PTR(-ENOMEM);
+ }
ret = virtio_gpu_framebuffer_init(dev, virtio_gpu_fb, mode_cmd, obj);
if (ret) {
--
2.33.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 7/7] virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
From: David Hildenbrand
[ Upstream commit 61082ad6a6e1f999eef7e7e90046486c87933b1e ]
The initial virtio-mem spec states that while unplugged memory should not
be read, the device still has to allow for reading unplugged memory inside
the usable region. The primary motivation for this default handling was
to simplify bringup of virtio-mem, because there were corner cases where
Linux might have accidentially read unplugged memory inside added Linux
memory blocks.
In the meantime, we:
1. Removed /dev/kmem in commit bbcd53c96071 ("drivers/char: remove
/dev/kmem for good")
2. Disallowed access to virtio-mem device memory via /dev/mem in
commit 2128f4e21aa2 ("virtio-mem: disallow mapping virtio-mem memory via
/dev/mem")
3. Sanitized access to virtio-mem device memory via /proc/kcore in
commit 0daa322b8ff9 ("fs/proc/kcore: don't read offline sections,
logically offline pages and hwpoisoned pages")
4. Sanitized access to virtio-mem device memory via /proc/vmcore in
commit ce2814622e84 ("virtio-mem: kdump mode to sanitize /proc/vmcore
access")
"Accidential" access to unplugged memory is no longer possible; we can
support the new VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature that will be
required by some hypervisors implementing virtio-mem in the near future.
Acked-by: Michael S. Tsirkin
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Marek Kedzierski
Cc: Hui Zhu
Cc: Sebastien Boeuf
Cc: Pankaj Gupta
Cc: Wei Yang
Signed-off-by: David Hildenbrand
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_mem.c | 1 +
include/uapi/linux/virtio_mem.h | 9 ++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index bef8ad6bf4661..78dfdc9c98a1c 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -2758,6 +2758,7 @@ static unsigned int virtio_mem_features[] = {
#if defined(CONFIG_NUMA) && defined(CONFIG_ACPI_NUMA)
VIRTIO_MEM_F_ACPI_PXM,
#endif
+ VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE,
};
static const struct virtio_device_id virtio_mem_id_table[] = {
diff --git a/include/uapi/linux/virtio_mem.h b/include/uapi/linux/virtio_mem.h
index 70e01c687d5eb..e9122f1d0e0cb 100644
--- a/include/uapi/linux/virtio_mem.h
+++ b/include/uapi/linux/virtio_mem.h
@@ -68,9 +68,10 @@
* explicitly triggered (VIRTIO_MEM_REQ_UNPLUG).
*
* There are no guarantees what will happen if unplugged memory is
- * read/written. Such memory should, in general, not be touched. E.g.,
- * even writing might succeed, but the values will simply be discarded at
- * random points in time.
+ * read/written. In general, unplugged memory should not be touched, because
+ * the resulting action is undefined. There is one exception: without
+ * VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, unplugged memory inside the usable
+ * region can be read, to simplify creation of memory dumps.
*
* It can happen that the device cannot process a request, because it is
* busy. The device driver has to retry later.
@@ -87,6 +88,8 @@
/* node_id is an ACPI PXM and is valid */
#define VIRTIO_MEM_F_ACPI_PXM 0
+/* unplugged memory must not be accessed */
+#define VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE1
/* --- virtio-mem: guest -> host requests --- */
--
2.33.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 3/4] virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
From: David Hildenbrand
[ Upstream commit 61082ad6a6e1f999eef7e7e90046486c87933b1e ]
The initial virtio-mem spec states that while unplugged memory should not
be read, the device still has to allow for reading unplugged memory inside
the usable region. The primary motivation for this default handling was
to simplify bringup of virtio-mem, because there were corner cases where
Linux might have accidentially read unplugged memory inside added Linux
memory blocks.
In the meantime, we:
1. Removed /dev/kmem in commit bbcd53c96071 ("drivers/char: remove
/dev/kmem for good")
2. Disallowed access to virtio-mem device memory via /dev/mem in
commit 2128f4e21aa2 ("virtio-mem: disallow mapping virtio-mem memory via
/dev/mem")
3. Sanitized access to virtio-mem device memory via /proc/kcore in
commit 0daa322b8ff9 ("fs/proc/kcore: don't read offline sections,
logically offline pages and hwpoisoned pages")
4. Sanitized access to virtio-mem device memory via /proc/vmcore in
commit ce2814622e84 ("virtio-mem: kdump mode to sanitize /proc/vmcore
access")
"Accidential" access to unplugged memory is no longer possible; we can
support the new VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature that will be
required by some hypervisors implementing virtio-mem in the near future.
Acked-by: Michael S. Tsirkin
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Marek Kedzierski
Cc: Hui Zhu
Cc: Sebastien Boeuf
Cc: Pankaj Gupta
Cc: Wei Yang
Signed-off-by: David Hildenbrand
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_mem.c | 1 +
include/uapi/linux/virtio_mem.h | 9 ++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 181e2f18beae5..1afdd8ca00bbb 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -1925,6 +1925,7 @@ static unsigned int virtio_mem_features[] = {
#if defined(CONFIG_NUMA) && defined(CONFIG_ACPI_NUMA)
VIRTIO_MEM_F_ACPI_PXM,
#endif
+ VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE,
};
static const struct virtio_device_id virtio_mem_id_table[] = {
diff --git a/include/uapi/linux/virtio_mem.h b/include/uapi/linux/virtio_mem.h
index 70e01c687d5eb..e9122f1d0e0cb 100644
--- a/include/uapi/linux/virtio_mem.h
+++ b/include/uapi/linux/virtio_mem.h
@@ -68,9 +68,10 @@
* explicitly triggered (VIRTIO_MEM_REQ_UNPLUG).
*
* There are no guarantees what will happen if unplugged memory is
- * read/written. Such memory should, in general, not be touched. E.g.,
- * even writing might succeed, but the values will simply be discarded at
- * random points in time.
+ * read/written. In general, unplugged memory should not be touched, because
+ * the resulting action is undefined. There is one exception: without
+ * VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, unplugged memory inside the usable
+ * region can be read, to simplify creation of memory dumps.
*
* It can happen that the device cannot process a request, because it is
* busy. The device driver has to retry later.
@@ -87,6 +88,8 @@
/* node_id is an ACPI PXM and is valid */
#define VIRTIO_MEM_F_ACPI_PXM 0
+/* unplugged memory must not be accessed */
+#define VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE1
/* --- virtio-mem: guest -> host requests --- */
--
2.33.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH AUTOSEL 5.15 7/7] virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
On Fri, Nov 26, 2021 at 09:51:23AM +0100, David Hildenbrand wrote:
On 26.11.21 03:30, Sasha Levin wrote:
From: David Hildenbrand
[ Upstream commit 61082ad6a6e1f999eef7e7e90046486c87933b1e ]
The initial virtio-mem spec states that while unplugged memory should not
be read, the device still has to allow for reading unplugged memory inside
the usable region. The primary motivation for this default handling was
to simplify bringup of virtio-mem, because there were corner cases where
Linux might have accidentially read unplugged memory inside added Linux
memory blocks.
In the meantime, we:
1. Removed /dev/kmem in commit bbcd53c96071 ("drivers/char: remove
/dev/kmem for good")
2. Disallowed access to virtio-mem device memory via /dev/mem in
commit 2128f4e21aa2 ("virtio-mem: disallow mapping virtio-mem memory via
/dev/mem")
3. Sanitized access to virtio-mem device memory via /proc/kcore in
commit 0daa322b8ff9 ("fs/proc/kcore: don't read offline sections,
logically offline pages and hwpoisoned pages")
4. Sanitized access to virtio-mem device memory via /proc/vmcore in
commit ce2814622e84 ("virtio-mem: kdump mode to sanitize /proc/vmcore
access")
"Accidential" access to unplugged memory is no longer possible; we can
support the new VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature that will be
required by some hypervisors implementing virtio-mem in the near future.
Acked-by: Michael S. Tsirkin
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Marek Kedzierski
Cc: Hui Zhu
Cc: Sebastien Boeuf
Cc: Pankaj Gupta
Cc: Wei Yang
Signed-off-by: David Hildenbrand
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_mem.c | 1 +
include/uapi/linux/virtio_mem.h | 9 ++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index bef8ad6bf4661..78dfdc9c98a1c 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -2758,6 +2758,7 @@ static unsigned int virtio_mem_features[] = {
#if defined(CONFIG_NUMA) && defined(CONFIG_ACPI_NUMA)
VIRTIO_MEM_F_ACPI_PXM,
#endif
+ VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE,
};
static const struct virtio_device_id virtio_mem_id_table[] = {
diff --git a/include/uapi/linux/virtio_mem.h b/include/uapi/linux/virtio_mem.h
index 70e01c687d5eb..e9122f1d0e0cb 100644
--- a/include/uapi/linux/virtio_mem.h
+++ b/include/uapi/linux/virtio_mem.h
@@ -68,9 +68,10 @@
* explicitly triggered (VIRTIO_MEM_REQ_UNPLUG).
*
* There are no guarantees what will happen if unplugged memory is
- * read/written. Such memory should, in general, not be touched. E.g.,
- * even writing might succeed, but the values will simply be discarded at
- * random points in time.
+ * read/written. In general, unplugged memory should not be touched, because
+ * the resulting action is undefined. There is one exception: without
+ * VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, unplugged memory inside the usable
+ * region can be read, to simplify creation of memory dumps.
*
* It can happen that the device cannot process a request, because it is
* busy. The device driver has to retry later.
@@ -87,6 +88,8 @@
/* node_id is an ACPI PXM and is valid */
#define VIRTIO_MEM_F_ACPI_PXM 0
+/* unplugged memory must not be accessed */
+#define VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE1
/* --- virtio-mem: guest -> host requests --- */
As 2. and 4. are part of v5.16-rc1 but not v5.15-stable
Nacked-by: David Hildenbrand
I'll drop them, thanks!
--
Thanks,
Sasha
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 40/43] vhost-vdpa: clean irqs before reseting vdpa device
From: Wu Zongyong [ Upstream commit ea8f17e44fa7d54fae287ccbe30ce269afb5ee42 ] Vdpa devices should be reset after unseting irqs of virtqueues, or we will get errors when killing qemu process: >> pi_update_irte: failed to update PI IRTE >> irq bypass consumer (token 65102a43) unregistration fails: -22 Signed-off-by: Wu Zongyong Link: https://lore.kernel.org/r/a2cb60cf73be9da5c4e6399242117d8818f975ae.1636946171.git.wuzongy...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/vdpa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index fdeb20f2f174c..dc4dccd35f59b 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -928,12 +928,12 @@ static int vhost_vdpa_release(struct inode *inode, struct file *filep) mutex_lock(&d->mutex); filep->private_data = NULL; + vhost_vdpa_clean_irq(v); vhost_vdpa_reset(v); vhost_dev_stop(&v->vdev); vhost_vdpa_iotlb_free(v); vhost_vdpa_free_domain(v); vhost_vdpa_config_put(v); - vhost_vdpa_clean_irq(v); vhost_dev_cleanup(&v->vdev); kfree(v->vdev.vqs); mutex_unlock(&d->mutex); -- 2.33.0 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 61/68] vhost-vdpa: clean irqs before reseting vdpa device
From: Wu Zongyong [ Upstream commit ea8f17e44fa7d54fae287ccbe30ce269afb5ee42 ] Vdpa devices should be reset after unseting irqs of virtqueues, or we will get errors when killing qemu process: >> pi_update_irte: failed to update PI IRTE >> irq bypass consumer (token 65102a43) unregistration fails: -22 Signed-off-by: Wu Zongyong Link: https://lore.kernel.org/r/a2cb60cf73be9da5c4e6399242117d8818f975ae.1636946171.git.wuzongy...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/vdpa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index 39039e0461175..e73bff6fcff98 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -1015,12 +1015,12 @@ static int vhost_vdpa_release(struct inode *inode, struct file *filep) mutex_lock(&d->mutex); filep->private_data = NULL; + vhost_vdpa_clean_irq(v); vhost_vdpa_reset(v); vhost_dev_stop(&v->vdev); vhost_vdpa_iotlb_free(v); vhost_vdpa_free_domain(v); vhost_vdpa_config_put(v); - vhost_vdpa_clean_irq(v); vhost_dev_cleanup(&v->vdev); kfree(v->vdev.vqs); mutex_unlock(&d->mutex); -- 2.33.0 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 22/29] virtio_net: fix rx_drops stat for small pkts
From: Wenliang Wang
[ Upstream commit 053c9e18c6f9cf82242ef35ac21cae1842725714 ]
We found the stat of rx drops for small pkts does not increment when
build_skb fail, it's not coherent with other mode's rx drops stat.
Signed-off-by: Wenliang Wang
Acked-by: Jason Wang
Acked-by: Michael S. Tsirkin
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/virtio_net.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4ad25a8b0870c..1231b48f7183e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -730,7 +730,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
pr_debug("%s: rx error: len %u exceeds max size %d\n",
dev->name, len, GOOD_PACKET_LEN);
dev->stats.rx_length_errors++;
- goto err_len;
+ goto err;
}
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -815,10 +815,8 @@ static struct sk_buff *receive_small(struct net_device
*dev,
rcu_read_unlock();
skb = build_skb(buf, buflen);
- if (!skb) {
- put_page(page);
+ if (!skb)
goto err;
- }
skb_reserve(skb, headroom - delta);
skb_put(skb, len);
if (!xdp_prog) {
@@ -829,13 +827,12 @@ static struct sk_buff *receive_small(struct net_device
*dev,
if (metasize)
skb_metadata_set(skb, metasize);
-err:
return skb;
err_xdp:
rcu_read_unlock();
stats->xdp_drops++;
-err_len:
+err:
stats->drops++;
put_page(page);
xdp_xmit:
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 17/19] virtio_net: fix rx_drops stat for small pkts
From: Wenliang Wang
[ Upstream commit 053c9e18c6f9cf82242ef35ac21cae1842725714 ]
We found the stat of rx drops for small pkts does not increment when
build_skb fail, it's not coherent with other mode's rx drops stat.
Signed-off-by: Wenliang Wang
Acked-by: Jason Wang
Acked-by: Michael S. Tsirkin
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/virtio_net.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cbe47eed7cc3c..3ba289b695f04 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -697,7 +697,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
pr_debug("%s: rx error: len %u exceeds max size %d\n",
dev->name, len, GOOD_PACKET_LEN);
dev->stats.rx_length_errors++;
- goto err_len;
+ goto err;
}
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -782,10 +782,8 @@ static struct sk_buff *receive_small(struct net_device
*dev,
rcu_read_unlock();
skb = build_skb(buf, buflen);
- if (!skb) {
- put_page(page);
+ if (!skb)
goto err;
- }
skb_reserve(skb, headroom - delta);
skb_put(skb, len);
if (!xdp_prog) {
@@ -796,13 +794,12 @@ static struct sk_buff *receive_small(struct net_device
*dev,
if (metasize)
skb_metadata_set(skb, metasize);
-err:
return skb;
err_xdp:
rcu_read_unlock();
stats->xdp_drops++;
-err_len:
+err:
stats->drops++;
put_page(page);
xdp_xmit:
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 088/217] drm: Return error codes from struct drm_driver.gem_create_object
From: Thomas Zimmermann
[ Upstream commit 4ff22f487f8c26b99cbe1678344595734c001a39 ]
GEM helper libraries use struct drm_driver.gem_create_object to let
drivers override GEM object allocation. On failure, the call returns
NULL.
Change the semantics to make the calls return a pointer-encoded error.
This aligns the callback with its callers. Fixes the ingenic driver,
which already returns an error pointer.
Also update the callers to handle the involved types more strictly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Steven Price
Acked-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20211130095255.26710-1-tzimmerm...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_gem_cma_helper.c| 17 ++---
drivers/gpu/drm/drm_gem_shmem_helper.c | 17 ++---
drivers/gpu/drm/drm_gem_vram_helper.c | 4 ++--
drivers/gpu/drm/lima/lima_gem.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
drivers/gpu/drm/v3d/v3d_bo.c| 4 ++--
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
include/drm/drm_drv.h | 5 +++--
9 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 9d05674550a4f..1e7e8cd64cb58 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -62,18 +62,21 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size,
bool private)
struct drm_gem_object *gem_obj;
int ret = 0;
- if (drm->driver->gem_create_object)
+ if (drm->driver->gem_create_object) {
gem_obj = drm->driver->gem_create_object(drm, size);
- else
- gem_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
- if (!gem_obj)
- return ERR_PTR(-ENOMEM);
+ if (IS_ERR(gem_obj))
+ return ERR_CAST(gem_obj);
+ cma_obj = to_drm_gem_cma_obj(gem_obj);
+ } else {
+ cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
+ if (!cma_obj)
+ return ERR_PTR(-ENOMEM);
+ gem_obj = &cma_obj->base;
+ }
if (!gem_obj->funcs)
gem_obj->funcs = &drm_gem_cma_default_funcs;
- cma_obj = container_of(gem_obj, struct drm_gem_cma_object, base);
-
if (private) {
drm_gem_private_object_init(drm, gem_obj, size);
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index bca0de92802ef..fe157bf278347 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -51,14 +51,17 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size,
bool private)
size = PAGE_ALIGN(size);
- if (dev->driver->gem_create_object)
+ if (dev->driver->gem_create_object) {
obj = dev->driver->gem_create_object(dev, size);
- else
- obj = kzalloc(sizeof(*shmem), GFP_KERNEL);
- if (!obj)
- return ERR_PTR(-ENOMEM);
-
- shmem = to_drm_gem_shmem_obj(obj);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+ shmem = to_drm_gem_shmem_obj(obj);
+ } else {
+ shmem = kzalloc(sizeof(*shmem), GFP_KERNEL);
+ if (!shmem)
+ return ERR_PTR(-ENOMEM);
+ obj = &shmem->base;
+ }
if (!obj->funcs)
obj->funcs = &drm_gem_shmem_funcs;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index bfa386b981346..3f00192215d11 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -197,8 +197,8 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
if (dev->driver->gem_create_object) {
gem = dev->driver->gem_create_object(dev, size);
- if (!gem)
- return ERR_PTR(-ENOMEM);
+ if (IS_ERR(gem))
+ return ERR_CAST(gem);
gbo = drm_gem_vram_of_gem(gem);
} else {
gbo = kzalloc(sizeof(*gbo), GFP_KERNEL);
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 640acc060467c..54823bd701a4b 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -221,7 +221,7 @@ struct drm_gem_object *lima_gem_create_object(struct
drm_device *dev, size_t siz
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
if (!bo)
- return NULL;
+ return ERR_PTR(-ENOMEM);
mutex_init(&bo->lock);
INIT_LIST_HEAD(&bo->va);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/
[PATCH AUTOSEL 5.16 15/19] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index a09dedc79f682..05740cba1cd89 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -166,6 +166,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 16/19] vdpa: clean up get_config_size ret value handling
From: Laura Abbott
[ Upstream commit 870aaff92e959e29d40f9cfdb5ed06ba2fc2dae0 ]
The return type of get_config_size is size_t so it makes
sense to change the type of the variable holding its result.
That said, this already got taken care of (differently, and arguably
not as well) by commit 3ed21c1451a1 ("vdpa: check that offsets are
within bounds").
The added 'c->off > size' test in that commit will be done as an
unsigned comparison on 32-bit (safe due to not being signed).
On a 64-bit platform, it will be done as a signed comparison, but in
that case the comparison will be done in 64-bit, and 'c->off' being an
u32 it will be valid thanks to the extended range (ie both values will
be positive in 64 bits).
So this was a real bug, but it was already addressed and marked for stable.
Signed-off-by: Laura Abbott
Reported-by: Luo Likang
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/vhost/vdpa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index e3c4f059b21a2..c31737a1da6aa 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -195,7 +195,7 @@ static int vhost_vdpa_config_validate(struct vhost_vdpa *v,
struct vhost_vdpa_config *c)
{
struct vdpa_device *vdpa = v->vdpa;
- long size = vdpa->config->get_config_size(vdpa);
+ size_t size = vdpa->config->get_config_size(vdpa);
if (c->len == 0 || c->off > size)
return -EINVAL;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 14/19] virtio-pci: fix the confusing error message
From: 王贇
[ Upstream commit 6017599bb25c20b7a68cbb8e7d534bdc1c36b5e4 ]
The error message on the failure of pfn check should tell
virtio-pci rather than virtio-mmio, just fix it.
Signed-off-by: Michael Wang
Suggested-by: Michael S. Tsirkin
Link:
https://lore.kernel.org/r/ae5e154e-ac59-f0fa-a7c7-091a2201f...@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index b3f8128b7983b..34141b9abe278 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -138,7 +138,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
q_pfn = virtqueue_get_desc_addr(vq) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT;
if (q_pfn >> 32) {
dev_err(&vp_dev->pci_dev->dev,
- "platform bug: legacy virtio-mmio must not be used with
RAM above 0x%llxGB\n",
+ "platform bug: legacy virtio-pci must not be used with
RAM above 0x%llxGB\n",
0x1ULL << (32 + PAGE_SHIFT - 30));
err = -E2BIG;
goto out_del_vq;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 13/19] net/mlx5_vdpa: Offer VIRTIO_NET_F_MTU when setting MTU
From: Eli Cohen [ Upstream commit 60af39c1f4cc92cc2785ef745c0c97558134d539 ] Make sure to offer VIRTIO_NET_F_MTU since we configure the MTU based on what was queried from the device. This allows the virtio driver to allocate large enough buffers based on the reported MTU. Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20211124170949.51725-1-e...@nvidia.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Reviewed-by: Si-Wei Liu Signed-off-by: Sasha Levin --- drivers/vdpa/mlx5/net/mlx5_vnet.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c index 63813fbb5f62a..d8e69340a25ae 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -1895,6 +1895,7 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device *vdev) ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR); ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_MQ); ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_STATUS); + ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_MTU); print_features(mvdev, ndev->mvdev.mlx_features, false); return ndev->mvdev.mlx_features; -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 17/19] vdpa/mlx5: Fix is_index_valid() to refer to features
From: Eli Cohen
[ Upstream commit f8ae3a489b21b05c39a0a1a7734f2a0188852177 ]
Make sure the decision whether an index received through a callback is
valid or not consults the negotiated features.
The motivation for this was due to a case encountered where I shut down
the VM. After the reset operation was called features were already
clear, I got get_vq_state() call which caused out array bounds
access since is_index_valid() reported the index value.
So this is more of not hit a bug since the call shouldn't have been made
first place.
Signed-off-by: Eli Cohen
Link: https://lore.kernel.org/r/2022083400.38418-4-e...@nvidia.com
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Si-Wei Liu
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index d8e69340a25ae..68ace0ad659f2 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -138,10 +138,14 @@ struct mlx5_vdpa_virtqueue {
static bool is_index_valid(struct mlx5_vdpa_dev *mvdev, u16 idx)
{
- if (unlikely(idx > mvdev->max_idx))
- return false;
+ if (!(mvdev->actual_features & BIT_ULL(VIRTIO_NET_F_MQ))) {
+ if (!(mvdev->actual_features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
+ return idx < 2;
+ else
+ return idx < 3;
+ }
- return true;
+ return idx <= mvdev->max_idx;
}
struct mlx5_vdpa_net {
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 11/16] virtio-pci: fix the confusing error message
From: 王贇
[ Upstream commit 6017599bb25c20b7a68cbb8e7d534bdc1c36b5e4 ]
The error message on the failure of pfn check should tell
virtio-pci rather than virtio-mmio, just fix it.
Signed-off-by: Michael Wang
Suggested-by: Michael S. Tsirkin
Link:
https://lore.kernel.org/r/ae5e154e-ac59-f0fa-a7c7-091a2201f...@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index d62e9835aeeca..0ede3bf43669d 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -144,7 +144,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
q_pfn = virtqueue_get_desc_addr(vq) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT;
if (q_pfn >> 32) {
dev_err(&vp_dev->pci_dev->dev,
- "platform bug: legacy virtio-mmio must not be used with
RAM above 0x%llxGB\n",
+ "platform bug: legacy virtio-pci must not be used with
RAM above 0x%llxGB\n",
0x1ULL << (32 + PAGE_SHIFT - 30));
err = -E2BIG;
goto out_del_vq;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 13/16] vdpa: clean up get_config_size ret value handling
From: Laura Abbott
[ Upstream commit 870aaff92e959e29d40f9cfdb5ed06ba2fc2dae0 ]
The return type of get_config_size is size_t so it makes
sense to change the type of the variable holding its result.
That said, this already got taken care of (differently, and arguably
not as well) by commit 3ed21c1451a1 ("vdpa: check that offsets are
within bounds").
The added 'c->off > size' test in that commit will be done as an
unsigned comparison on 32-bit (safe due to not being signed).
On a 64-bit platform, it will be done as a signed comparison, but in
that case the comparison will be done in 64-bit, and 'c->off' being an
u32 it will be valid thanks to the extended range (ie both values will
be positive in 64 bits).
So this was a real bug, but it was already addressed and marked for stable.
Signed-off-by: Laura Abbott
Reported-by: Luo Likang
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/vhost/vdpa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index d62f05d056b7b..913cd465f9f1e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -195,7 +195,7 @@ static int vhost_vdpa_config_validate(struct vhost_vdpa *v,
struct vhost_vdpa_config *c)
{
struct vdpa_device *vdpa = v->vdpa;
- long size = vdpa->config->get_config_size(vdpa);
+ size_t size = vdpa->config->get_config_size(vdpa);
if (c->len == 0 || c->off > size)
return -EINVAL;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 14/16] vdpa/mlx5: Fix is_index_valid() to refer to features
From: Eli Cohen
[ Upstream commit f8ae3a489b21b05c39a0a1a7734f2a0188852177 ]
Make sure the decision whether an index received through a callback is
valid or not consults the negotiated features.
The motivation for this was due to a case encountered where I shut down
the VM. After the reset operation was called features were already
clear, I got get_vq_state() call which caused out array bounds
access since is_index_valid() reported the index value.
So this is more of not hit a bug since the call shouldn't have been made
first place.
Signed-off-by: Eli Cohen
Link: https://lore.kernel.org/r/2022083400.38418-4-e...@nvidia.com
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Si-Wei Liu
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index ae85d2dd6eb76..d538fbc472666 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -137,10 +137,14 @@ struct mlx5_vdpa_virtqueue {
static bool is_index_valid(struct mlx5_vdpa_dev *mvdev, u16 idx)
{
- if (unlikely(idx > mvdev->max_idx))
- return false;
+ if (!(mvdev->actual_features & BIT_ULL(VIRTIO_NET_F_MQ))) {
+ if (!(mvdev->actual_features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
+ return idx < 2;
+ else
+ return idx < 3;
+ }
- return true;
+ return idx <= mvdev->max_idx;
}
struct mlx5_vdpa_net {
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 12/16] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index a09dedc79f682..05740cba1cd89 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -166,6 +166,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 8/9] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index a09dedc79f682..05740cba1cd89 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -166,6 +166,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 7/9] virtio-pci: fix the confusing error message
From: 王贇
[ Upstream commit 6017599bb25c20b7a68cbb8e7d534bdc1c36b5e4 ]
The error message on the failure of pfn check should tell
virtio-pci rather than virtio-mmio, just fix it.
Signed-off-by: Michael Wang
Suggested-by: Michael S. Tsirkin
Link:
https://lore.kernel.org/r/ae5e154e-ac59-f0fa-a7c7-091a2201f...@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index d62e9835aeeca..0ede3bf43669d 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -144,7 +144,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
q_pfn = virtqueue_get_desc_addr(vq) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT;
if (q_pfn >> 32) {
dev_err(&vp_dev->pci_dev->dev,
- "platform bug: legacy virtio-mmio must not be used with
RAM above 0x%llxGB\n",
+ "platform bug: legacy virtio-pci must not be used with
RAM above 0x%llxGB\n",
0x1ULL << (32 + PAGE_SHIFT - 30));
err = -E2BIG;
goto out_del_vq;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 6/8] virtio-pci: fix the confusing error message
From: 王贇
[ Upstream commit 6017599bb25c20b7a68cbb8e7d534bdc1c36b5e4 ]
The error message on the failure of pfn check should tell
virtio-pci rather than virtio-mmio, just fix it.
Signed-off-by: Michael Wang
Suggested-by: Michael S. Tsirkin
Link:
https://lore.kernel.org/r/ae5e154e-ac59-f0fa-a7c7-091a2201f...@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index d62e9835aeeca..0ede3bf43669d 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -144,7 +144,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
q_pfn = virtqueue_get_desc_addr(vq) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT;
if (q_pfn >> 32) {
dev_err(&vp_dev->pci_dev->dev,
- "platform bug: legacy virtio-mmio must not be used with
RAM above 0x%llxGB\n",
+ "platform bug: legacy virtio-pci must not be used with
RAM above 0x%llxGB\n",
0x1ULL << (32 + PAGE_SHIFT - 30));
err = -E2BIG;
goto out_del_vq;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 7/8] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index 056308008288c..fd8e9f70b06d3 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -166,6 +166,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.19 4/5] virtio-pci: fix the confusing error message
From: 王贇
[ Upstream commit 6017599bb25c20b7a68cbb8e7d534bdc1c36b5e4 ]
The error message on the failure of pfn check should tell
virtio-pci rather than virtio-mmio, just fix it.
Signed-off-by: Michael Wang
Suggested-by: Michael S. Tsirkin
Link:
https://lore.kernel.org/r/ae5e154e-ac59-f0fa-a7c7-091a2201f...@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index de062fb201bc2..61add42862017 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -145,7 +145,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
q_pfn = virtqueue_get_desc_addr(vq) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT;
if (q_pfn >> 32) {
dev_err(&vp_dev->pci_dev->dev,
- "platform bug: legacy virtio-mmio must not be used with
RAM above 0x%llxGB\n",
+ "platform bug: legacy virtio-pci must not be used with
RAM above 0x%llxGB\n",
0x1ULL << (32 + PAGE_SHIFT - 30));
err = -E2BIG;
goto out_del_vq;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.19 5/5] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index 55090d9f9de0d..2d6abe1c0dbec 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -167,6 +167,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.14 4/4] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index 682fc58e1f752..3abe6833be88e 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -166,6 +166,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.14 3/4] virtio-pci: fix the confusing error message
From: 王贇
[ Upstream commit 6017599bb25c20b7a68cbb8e7d534bdc1c36b5e4 ]
The error message on the failure of pfn check should tell
virtio-pci rather than virtio-mmio, just fix it.
Signed-off-by: Michael Wang
Suggested-by: Michael S. Tsirkin
Link:
https://lore.kernel.org/r/ae5e154e-ac59-f0fa-a7c7-091a2201f...@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index de062fb201bc2..61add42862017 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -145,7 +145,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
q_pfn = virtqueue_get_desc_addr(vq) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT;
if (q_pfn >> 32) {
dev_err(&vp_dev->pci_dev->dev,
- "platform bug: legacy virtio-mmio must not be used with
RAM above 0x%llxGB\n",
+ "platform bug: legacy virtio-pci must not be used with
RAM above 0x%llxGB\n",
0x1ULL << (32 + PAGE_SHIFT - 30));
err = -E2BIG;
goto out_del_vq;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.9 3/4] virtio-pci: fix the confusing error message
From: 王贇
[ Upstream commit 6017599bb25c20b7a68cbb8e7d534bdc1c36b5e4 ]
The error message on the failure of pfn check should tell
virtio-pci rather than virtio-mmio, just fix it.
Signed-off-by: Michael Wang
Suggested-by: Michael S. Tsirkin
Link:
https://lore.kernel.org/r/ae5e154e-ac59-f0fa-a7c7-091a2201f...@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Sasha Levin
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index fbc4761987e85..be4e099c117ac 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -143,7 +143,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
q_pfn = virtqueue_get_desc_addr(vq) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT;
if (q_pfn >> 32) {
dev_err(&vp_dev->pci_dev->dev,
- "platform bug: legacy virtio-mmio must not be used with
RAM above 0x%llxGB\n",
+ "platform bug: legacy virtio-pci must not be used with
RAM above 0x%llxGB\n",
0x1ULL << (32 + PAGE_SHIFT - 30));
err = -E2BIG;
goto out_del_vq;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.9 4/4] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index 682fc58e1f752..3abe6833be88e 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -166,6 +166,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.4 3/3] vhost/test: fix memory leak of vhost virtqueues
From: Xianting Tian [ Upstream commit 080063920777af65105e5953e2851e036376e3ea ] We need free the vqs in .release(), which are allocated in .open(). Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20211228030924.3468439-1-xianting.t...@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- drivers/vhost/test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c index ca451452a..8a438642255ad 100644 --- a/drivers/vhost/test.c +++ b/drivers/vhost/test.c @@ -166,6 +166,7 @@ static int vhost_test_release(struct inode *inode, struct file *f) /* We do an extra flush before freeing memory, * since jobs can re-queue themselves. */ vhost_test_flush(n); + kfree(n->dev.vqs); kfree(n); return 0; } -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 06/13] virtio_console: break out of buf poll on remove
From: "Michael S. Tsirkin" [ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin --- drivers/char/virtio_console.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 660c5c388c29..f864b17be7e3 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1957,6 +1957,13 @@ static void virtcons_remove(struct virtio_device *vdev) list_del(&portdev->list); spin_unlock_irq(&pdrvdata_lock); + /* Device is going away, exit any polling for buffers */ + virtio_break_device(vdev); + if (use_multiport(portdev)) + flush_work(&portdev->control_work); + else + flush_work(&portdev->config_work); + /* Disable interrupts for vqs */ vdev->config->reset(vdev); /* Finish up work that's lined up */ -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 07/13] vdpa/mlx5: should verify CTRL_VQ feature exists for MQ
From: Si-Wei Liu
[ Upstream commit 30c22f3816ffef8aa21a000e93c4ee1402a6ea65 ]
Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit requirements:
"VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
There's assumption in the mlx5_vdpa multiqueue code that MQ must come
together with CTRL_VQ. However, there's nowhere in the upper layer to
guarantee this assumption would hold. Were there an untrusted driver
sending down MQ without CTRL_VQ, it would compromise various spots for
e.g. is_index_valid() and is_ctrl_vq_idx(). Although this doesn't end
up with immediate panic or security loophole as of today's code, the
chance for this to be taken advantage of due to future code change is
not zero.
Harden the crispy assumption by failing the set_driver_features() call
when seeing (MQ && !CTRL_VQ). For that end, verify_min_features() is
renamed to verify_driver_features() to reflect the fact that it now does
more than just validate the minimum features. verify_driver_features()
is now used to accommodate various checks against the driver features
for set_driver_features().
Signed-off-by: Si-Wei Liu
Link:
https://lore.kernel.org/r/1642206481-30721-3-git-send-email-si-wei@oracle.com
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Eli Cohen
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index ef6da39ccb3f..ee4385978e6a 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1900,11 +1900,25 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device
*vdev)
return ndev->mvdev.mlx_features;
}
-static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features)
+static int verify_driver_features(struct mlx5_vdpa_dev *mvdev, u64 features)
{
+ /* Minimum features to expect */
if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
return -EOPNOTSUPP;
+ /* Double check features combination sent down by the driver.
+* Fail invalid features due to absence of the depended feature.
+*
+* Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit
+* requirements: "VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
+* By failing the invalid features sent down by untrusted drivers,
+* we're assured the assumption made upon is_index_valid() and
+* is_ctrl_vq_idx() will not be compromised.
+*/
+ if ((features & (BIT_ULL(VIRTIO_NET_F_MQ) |
BIT_ULL(VIRTIO_NET_F_CTRL_VQ))) ==
+BIT_ULL(VIRTIO_NET_F_MQ))
+ return -EINVAL;
+
return 0;
}
@@ -1980,7 +1994,7 @@ static int mlx5_vdpa_set_features(struct vdpa_device
*vdev, u64 features)
print_features(mvdev, features, true);
- err = verify_min_features(mvdev, features);
+ err = verify_driver_features(mvdev, features);
if (err)
return err;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 09/13] tools/virtio: fix virtio_test execution
From: Stefano Garzarella [ Upstream commit 32f1b53fe8f03d962423ba81f8e92af5839814da ] virtio_test hangs on __vring_new_virtqueue() because `vqs_list_lock` is not initialized. Let's initialize it in vdev_info_init(). Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20220118150631.167015-1-sgarz...@redhat.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- tools/virtio/virtio_test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c index cb3f29c09aff..23f142af544a 100644 --- a/tools/virtio/virtio_test.c +++ b/tools/virtio/virtio_test.c @@ -130,6 +130,7 @@ static void vdev_info_init(struct vdev_info* dev, unsigned long long features) memset(dev, 0, sizeof *dev); dev->vdev.features = features; INIT_LIST_HEAD(&dev->vdev.vqs); + spin_lock_init(&dev->vdev.vqs_list_lock); dev->buf_size = 1024; dev->buf = malloc(dev->buf_size); assert(dev->buf); -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 06/13] virtio_console: break out of buf poll on remove
From: "Michael S. Tsirkin" [ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin --- drivers/char/virtio_console.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 7eaf303a7a86..3adf04766e98 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1956,6 +1956,13 @@ static void virtcons_remove(struct virtio_device *vdev) list_del(&portdev->list); spin_unlock_irq(&pdrvdata_lock); + /* Device is going away, exit any polling for buffers */ + virtio_break_device(vdev); + if (use_multiport(portdev)) + flush_work(&portdev->control_work); + else + flush_work(&portdev->config_work); + /* Disable interrupts for vqs */ vdev->config->reset(vdev); /* Finish up work that's lined up */ -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 07/13] vdpa/mlx5: should verify CTRL_VQ feature exists for MQ
From: Si-Wei Liu
[ Upstream commit 30c22f3816ffef8aa21a000e93c4ee1402a6ea65 ]
Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit requirements:
"VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
There's assumption in the mlx5_vdpa multiqueue code that MQ must come
together with CTRL_VQ. However, there's nowhere in the upper layer to
guarantee this assumption would hold. Were there an untrusted driver
sending down MQ without CTRL_VQ, it would compromise various spots for
e.g. is_index_valid() and is_ctrl_vq_idx(). Although this doesn't end
up with immediate panic or security loophole as of today's code, the
chance for this to be taken advantage of due to future code change is
not zero.
Harden the crispy assumption by failing the set_driver_features() call
when seeing (MQ && !CTRL_VQ). For that end, verify_min_features() is
renamed to verify_driver_features() to reflect the fact that it now does
more than just validate the minimum features. verify_driver_features()
is now used to accommodate various checks against the driver features
for set_driver_features().
Signed-off-by: Si-Wei Liu
Link:
https://lore.kernel.org/r/1642206481-30721-3-git-send-email-si-wei@oracle.com
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Eli Cohen
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 1afbda216df5..6abbf1a4b06c 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1857,11 +1857,25 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device
*vdev)
return ndev->mvdev.mlx_features;
}
-static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features)
+static int verify_driver_features(struct mlx5_vdpa_dev *mvdev, u64 features)
{
+ /* Minimum features to expect */
if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
return -EOPNOTSUPP;
+ /* Double check features combination sent down by the driver.
+* Fail invalid features due to absence of the depended feature.
+*
+* Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit
+* requirements: "VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
+* By failing the invalid features sent down by untrusted drivers,
+* we're assured the assumption made upon is_index_valid() and
+* is_ctrl_vq_idx() will not be compromised.
+*/
+ if ((features & (BIT_ULL(VIRTIO_NET_F_MQ) |
BIT_ULL(VIRTIO_NET_F_CTRL_VQ))) ==
+BIT_ULL(VIRTIO_NET_F_MQ))
+ return -EINVAL;
+
return 0;
}
@@ -1937,7 +1951,7 @@ static int mlx5_vdpa_set_features(struct vdpa_device
*vdev, u64 features)
print_features(mvdev, features, true);
- err = verify_min_features(mvdev, features);
+ err = verify_driver_features(mvdev, features);
if (err)
return err;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 09/13] tools/virtio: fix virtio_test execution
From: Stefano Garzarella [ Upstream commit 32f1b53fe8f03d962423ba81f8e92af5839814da ] virtio_test hangs on __vring_new_virtqueue() because `vqs_list_lock` is not initialized. Let's initialize it in vdev_info_init(). Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20220118150631.167015-1-sgarz...@redhat.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- tools/virtio/virtio_test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c index cb3f29c09aff..23f142af544a 100644 --- a/tools/virtio/virtio_test.c +++ b/tools/virtio/virtio_test.c @@ -130,6 +130,7 @@ static void vdev_info_init(struct vdev_info* dev, unsigned long long features) memset(dev, 0, sizeof *dev); dev->vdev.features = features; INIT_LIST_HEAD(&dev->vdev.vqs); + spin_lock_init(&dev->vdev.vqs_list_lock); dev->buf_size = 1024; dev->buf = malloc(dev->buf_size); assert(dev->buf); -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 05/12] virtio_console: break out of buf poll on remove
From: "Michael S. Tsirkin" [ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin --- drivers/char/virtio_console.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 673522874cec..3dd4deb60adb 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1959,6 +1959,13 @@ static void virtcons_remove(struct virtio_device *vdev) list_del(&portdev->list); spin_unlock_irq(&pdrvdata_lock); + /* Device is going away, exit any polling for buffers */ + virtio_break_device(vdev); + if (use_multiport(portdev)) + flush_work(&portdev->control_work); + else + flush_work(&portdev->config_work); + /* Disable interrupts for vqs */ vdev->config->reset(vdev); /* Finish up work that's lined up */ -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 06/12] vdpa/mlx5: should verify CTRL_VQ feature exists for MQ
From: Si-Wei Liu
[ Upstream commit 30c22f3816ffef8aa21a000e93c4ee1402a6ea65 ]
Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit requirements:
"VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
There's assumption in the mlx5_vdpa multiqueue code that MQ must come
together with CTRL_VQ. However, there's nowhere in the upper layer to
guarantee this assumption would hold. Were there an untrusted driver
sending down MQ without CTRL_VQ, it would compromise various spots for
e.g. is_index_valid() and is_ctrl_vq_idx(). Although this doesn't end
up with immediate panic or security loophole as of today's code, the
chance for this to be taken advantage of due to future code change is
not zero.
Harden the crispy assumption by failing the set_driver_features() call
when seeing (MQ && !CTRL_VQ). For that end, verify_min_features() is
renamed to verify_driver_features() to reflect the fact that it now does
more than just validate the minimum features. verify_driver_features()
is now used to accommodate various checks against the driver features
for set_driver_features().
Signed-off-by: Si-Wei Liu
Link:
https://lore.kernel.org/r/1642206481-30721-3-git-send-email-si-wei@oracle.com
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Eli Cohen
Acked-by: Jason Wang
Signed-off-by: Sasha Levin
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 65d6f8fd81e7..577ff786f11b 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1482,11 +1482,25 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device
*vdev)
return ndev->mvdev.mlx_features;
}
-static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features)
+static int verify_driver_features(struct mlx5_vdpa_dev *mvdev, u64 features)
{
+ /* Minimum features to expect */
if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
return -EOPNOTSUPP;
+ /* Double check features combination sent down by the driver.
+* Fail invalid features due to absence of the depended feature.
+*
+* Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit
+* requirements: "VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
+* By failing the invalid features sent down by untrusted drivers,
+* we're assured the assumption made upon is_index_valid() and
+* is_ctrl_vq_idx() will not be compromised.
+*/
+ if ((features & (BIT_ULL(VIRTIO_NET_F_MQ) |
BIT_ULL(VIRTIO_NET_F_CTRL_VQ))) ==
+BIT_ULL(VIRTIO_NET_F_MQ))
+ return -EINVAL;
+
return 0;
}
@@ -1544,7 +1558,7 @@ static int mlx5_vdpa_set_features(struct vdpa_device
*vdev, u64 features)
print_features(mvdev, features, true);
- err = verify_min_features(mvdev, features);
+ err = verify_driver_features(mvdev, features);
if (err)
return err;
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 08/12] tools/virtio: fix virtio_test execution
From: Stefano Garzarella [ Upstream commit 32f1b53fe8f03d962423ba81f8e92af5839814da ] virtio_test hangs on __vring_new_virtqueue() because `vqs_list_lock` is not initialized. Let's initialize it in vdev_info_init(). Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20220118150631.167015-1-sgarz...@redhat.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin --- tools/virtio/virtio_test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c index cb3f29c09aff..23f142af544a 100644 --- a/tools/virtio/virtio_test.c +++ b/tools/virtio/virtio_test.c @@ -130,6 +130,7 @@ static void vdev_info_init(struct vdev_info* dev, unsigned long long features) memset(dev, 0, sizeof *dev); dev->vdev.features = features; INIT_LIST_HEAD(&dev->vdev.vqs); + spin_lock_init(&dev->vdev.vqs_list_lock); dev->buf_size = 1024; dev->buf = malloc(dev->buf_size); assert(dev->buf); -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 3/7] virtio_console: break out of buf poll on remove
From: "Michael S. Tsirkin" [ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin --- drivers/char/virtio_console.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index b453029487a1..2660a0c5483a 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1961,6 +1961,13 @@ static void virtcons_remove(struct virtio_device *vdev) list_del(&portdev->list); spin_unlock_irq(&pdrvdata_lock); + /* Device is going away, exit any polling for buffers */ + virtio_break_device(vdev); + if (use_multiport(portdev)) + flush_work(&portdev->control_work); + else + flush_work(&portdev->config_work); + /* Disable interrupts for vqs */ vdev->config->reset(vdev); /* Finish up work that's lined up */ -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.19 2/6] virtio_console: break out of buf poll on remove
From: "Michael S. Tsirkin" [ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin --- drivers/char/virtio_console.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index cdf441942bae..ac0b84afabe7 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1985,6 +1985,13 @@ static void virtcons_remove(struct virtio_device *vdev) list_del(&portdev->list); spin_unlock_irq(&pdrvdata_lock); + /* Device is going away, exit any polling for buffers */ + virtio_break_device(vdev); + if (use_multiport(portdev)) + flush_work(&portdev->control_work); + else + flush_work(&portdev->config_work); + /* Disable interrupts for vqs */ vdev->config->reset(vdev); /* Finish up work that's lined up */ -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.14 1/3] virtio_console: break out of buf poll on remove
From: "Michael S. Tsirkin" [ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin --- drivers/char/virtio_console.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 0fb3a8e62e62..2140d401523f 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -2001,6 +2001,13 @@ static void virtcons_remove(struct virtio_device *vdev) list_del(&portdev->list); spin_unlock_irq(&pdrvdata_lock); + /* Device is going away, exit any polling for buffers */ + virtio_break_device(vdev); + if (use_multiport(portdev)) + flush_work(&portdev->control_work); + else + flush_work(&portdev->config_work); + /* Disable interrupts for vqs */ vdev->config->reset(vdev); /* Finish up work that's lined up */ -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.9 1/2] virtio_console: break out of buf poll on remove
From: "Michael S. Tsirkin" [ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin --- drivers/char/virtio_console.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 2632b0fdb1b5..a6b6dc204c1f 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -2004,6 +2004,13 @@ static void virtcons_remove(struct virtio_device *vdev) list_del(&portdev->list); spin_unlock_irq(&pdrvdata_lock); + /* Device is going away, exit any polling for buffers */ + virtio_break_device(vdev); + if (use_multiport(portdev)) + flush_work(&portdev->control_work); + else + flush_work(&portdev->config_work); + /* Disable interrupts for vqs */ vdev->config->reset(vdev); /* Finish up work that's lined up */ -- 2.34.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.17 114/149] tuntap: add sanity checks about msg_controllen in sendmsg
From: Harold Huang
[ Upstream commit 74a335a07a17d131b9263bfdbdcb5e40673ca9ca ]
In patch [1], tun_msg_ctl was added to allow pass batched xdp buffers to
tun_sendmsg. Although we donot use msg_controllen in this path, we should
check msg_controllen to make sure the caller pass a valid msg_ctl.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe8dd45bb7556246c6b76277b1ba4296c91c2505
Reported-by: Eric Dumazet
Suggested-by: Jason Wang
Signed-off-by: Harold Huang
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20220303022441.383865-1-baymaxhu...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/tap.c | 3 ++-
drivers/net/tun.c | 3 ++-
drivers/vhost/net.c | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 8e3a28ba6b28..ba2ef5437e16 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1198,7 +1198,8 @@ static int tap_sendmsg(struct socket *sock, struct msghdr
*m,
struct xdp_buff *xdp;
int i;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
for (i = 0; i < ctl->num; i++) {
xdp = &((struct xdp_buff *)ctl->ptr)[i];
tap_get_user_xdp(q, xdp);
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index fed85447701a..de999e0fedbc 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2489,7 +2489,8 @@ static int tun_sendmsg(struct socket *sock, struct msghdr
*m, size_t total_len)
if (!tun)
return -EBADFD;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
struct tun_page tpage;
int n = ctl->num;
int flush = 0;
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 28ef323882fb..792ab5f23647 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -473,6 +473,7 @@ static void vhost_tx_batch(struct vhost_net *net,
goto signal_used;
msghdr->msg_control = &ctl;
+ msghdr->msg_controllen = sizeof(ctl);
err = sock->ops->sendmsg(sock, msghdr, 0);
if (unlikely(err < 0)) {
vq_err(&nvq->vq, "Fail to batch sending packets\n");
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.16 079/109] tuntap: add sanity checks about msg_controllen in sendmsg
From: Harold Huang
[ Upstream commit 74a335a07a17d131b9263bfdbdcb5e40673ca9ca ]
In patch [1], tun_msg_ctl was added to allow pass batched xdp buffers to
tun_sendmsg. Although we donot use msg_controllen in this path, we should
check msg_controllen to make sure the caller pass a valid msg_ctl.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe8dd45bb7556246c6b76277b1ba4296c91c2505
Reported-by: Eric Dumazet
Suggested-by: Jason Wang
Signed-off-by: Harold Huang
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20220303022441.383865-1-baymaxhu...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/tap.c | 3 ++-
drivers/net/tun.c | 3 ++-
drivers/vhost/net.c | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 8e3a28ba6b28..ba2ef5437e16 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1198,7 +1198,8 @@ static int tap_sendmsg(struct socket *sock, struct msghdr
*m,
struct xdp_buff *xdp;
int i;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
for (i = 0; i < ctl->num; i++) {
xdp = &((struct xdp_buff *)ctl->ptr)[i];
tap_get_user_xdp(q, xdp);
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 45a67e72a02c..02de8d998bfa 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2489,7 +2489,8 @@ static int tun_sendmsg(struct socket *sock, struct msghdr
*m, size_t total_len)
if (!tun)
return -EBADFD;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
struct tun_page tpage;
int n = ctl->num;
int flush = 0;
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 28ef323882fb..792ab5f23647 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -473,6 +473,7 @@ static void vhost_tx_batch(struct vhost_net *net,
goto signal_used;
msghdr->msg_control = &ctl;
+ msghdr->msg_controllen = sizeof(ctl);
err = sock->ops->sendmsg(sock, msghdr, 0);
if (unlikely(err < 0)) {
vq_err(&nvq->vq, "Fail to batch sending packets\n");
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.15 68/98] tuntap: add sanity checks about msg_controllen in sendmsg
From: Harold Huang
[ Upstream commit 74a335a07a17d131b9263bfdbdcb5e40673ca9ca ]
In patch [1], tun_msg_ctl was added to allow pass batched xdp buffers to
tun_sendmsg. Although we donot use msg_controllen in this path, we should
check msg_controllen to make sure the caller pass a valid msg_ctl.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe8dd45bb7556246c6b76277b1ba4296c91c2505
Reported-by: Eric Dumazet
Suggested-by: Jason Wang
Signed-off-by: Harold Huang
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20220303022441.383865-1-baymaxhu...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/tap.c | 3 ++-
drivers/net/tun.c | 3 ++-
drivers/vhost/net.c | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 8e3a28ba6b28..ba2ef5437e16 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1198,7 +1198,8 @@ static int tap_sendmsg(struct socket *sock, struct msghdr
*m,
struct xdp_buff *xdp;
int i;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
for (i = 0; i < ctl->num; i++) {
xdp = &((struct xdp_buff *)ctl->ptr)[i];
tap_get_user_xdp(q, xdp);
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 45a67e72a02c..02de8d998bfa 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2489,7 +2489,8 @@ static int tun_sendmsg(struct socket *sock, struct msghdr
*m, size_t total_len)
if (!tun)
return -EBADFD;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
struct tun_page tpage;
int n = ctl->num;
int flush = 0;
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 28ef323882fb..792ab5f23647 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -473,6 +473,7 @@ static void vhost_tx_batch(struct vhost_net *net,
goto signal_used;
msghdr->msg_control = &ctl;
+ msghdr->msg_controllen = sizeof(ctl);
err = sock->ops->sendmsg(sock, msghdr, 0);
if (unlikely(err < 0)) {
vq_err(&nvq->vq, "Fail to batch sending packets\n");
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 44/65] tuntap: add sanity checks about msg_controllen in sendmsg
From: Harold Huang
[ Upstream commit 74a335a07a17d131b9263bfdbdcb5e40673ca9ca ]
In patch [1], tun_msg_ctl was added to allow pass batched xdp buffers to
tun_sendmsg. Although we donot use msg_controllen in this path, we should
check msg_controllen to make sure the caller pass a valid msg_ctl.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe8dd45bb7556246c6b76277b1ba4296c91c2505
Reported-by: Eric Dumazet
Suggested-by: Jason Wang
Signed-off-by: Harold Huang
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20220303022441.383865-1-baymaxhu...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/tap.c | 3 ++-
drivers/net/tun.c | 3 ++-
drivers/vhost/net.c | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index f549d3a8e59c..8f7bb15206e9 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1202,7 +1202,8 @@ static int tap_sendmsg(struct socket *sock, struct msghdr
*m,
struct xdp_buff *xdp;
int i;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
for (i = 0; i < ctl->num; i++) {
xdp = &((struct xdp_buff *)ctl->ptr)[i];
tap_get_user_xdp(q, xdp);
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ffbc7eda95ee..55ce141c93c7 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2499,7 +2499,8 @@ static int tun_sendmsg(struct socket *sock, struct msghdr
*m, size_t total_len)
if (!tun)
return -EBADFD;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
struct tun_page tpage;
int n = ctl->num;
int flush = 0;
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index da02c3e96e7b..e303f6f073d2 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -472,6 +472,7 @@ static void vhost_tx_batch(struct vhost_net *net,
goto signal_used;
msghdr->msg_control = &ctl;
+ msghdr->msg_controllen = sizeof(ctl);
err = sock->ops->sendmsg(sock, msghdr, 0);
if (unlikely(err < 0)) {
vq_err(&nvq->vq, "Fail to batch sending packets\n");
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 26/37] tuntap: add sanity checks about msg_controllen in sendmsg
From: Harold Huang
[ Upstream commit 74a335a07a17d131b9263bfdbdcb5e40673ca9ca ]
In patch [1], tun_msg_ctl was added to allow pass batched xdp buffers to
tun_sendmsg. Although we donot use msg_controllen in this path, we should
check msg_controllen to make sure the caller pass a valid msg_ctl.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe8dd45bb7556246c6b76277b1ba4296c91c2505
Reported-by: Eric Dumazet
Suggested-by: Jason Wang
Signed-off-by: Harold Huang
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20220303022441.383865-1-baymaxhu...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/tap.c | 3 ++-
drivers/net/tun.c | 3 ++-
drivers/vhost/net.c | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index f285422a8071..f870d08bb1f8 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1214,7 +1214,8 @@ static int tap_sendmsg(struct socket *sock, struct msghdr
*m,
struct xdp_buff *xdp;
int i;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
for (i = 0; i < ctl->num; i++) {
xdp = &((struct xdp_buff *)ctl->ptr)[i];
tap_get_user_xdp(q, xdp);
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 10211ea60514..d9993884a97d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2561,7 +2561,8 @@ static int tun_sendmsg(struct socket *sock, struct msghdr
*m, size_t total_len)
if (!tun)
return -EBADFD;
- if (ctl && (ctl->type == TUN_MSG_PTR)) {
+ if (m->msg_controllen == sizeof(struct tun_msg_ctl) &&
+ ctl && ctl->type == TUN_MSG_PTR) {
struct tun_page tpage;
int n = ctl->num;
int flush = 0;
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index cec9173aac6f..1058aba8d573 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -472,6 +472,7 @@ static void vhost_tx_batch(struct vhost_net *net,
goto signal_used;
msghdr->msg_control = &ctl;
+ msghdr->msg_controllen = sizeof(ctl);
err = sock->ops->sendmsg(sock, msghdr, 0);
if (unlikely(err < 0)) {
vq_err(&nvq->vq, "Fail to batch sending packets\n");
--
2.34.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.9 082/111] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 4d944a0dff3e9..fdd7671a7b126 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -80,8 +80,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(&vgdev->display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(&vgdev->display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 53af60d484a44..9d2abdbd865a7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,9 +684,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(&vgdev->display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
}
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.8 076/101] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 0a5c8cf409fb8..dc8cb8dfce58e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -80,8 +80,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(&vgdev->display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(&vgdev->display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9e663a5d99526..2517450bf46ba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,9 +684,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(&vgdev->display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
}
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 60/80] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index c190702fab726..6dcc05ab31eba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -96,8 +96,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(&vgdev->display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(&vgdev->display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 7ac20490e1b4c..92022a83bbd5e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -572,9 +572,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(&vgdev->display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
}
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.19 45/56] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 65060c08522d7..22397a23780c0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(&vgdev->display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(&vgdev->display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 608906f06cedd..3e72c6dac0ffe 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -566,9 +566,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(&vgdev->display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
}
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.14 42/52] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 6400506a06b07..bed450fbb2168 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(&vgdev->display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(&vgdev->display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index a3be65e689fd2..a956c73ea85e5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -563,9 +563,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(&vgdev->display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
}
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.9 35/41] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 036b0fbae0fb7..ba7855da7c7f6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(&vgdev->display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(&vgdev->display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 772a5a3b0ce1a..18e8fcad6690b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -596,9 +596,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(&vgdev->display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
}
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.4 27/33] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 06496a1281622..476b9993b0682 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(&vgdev->display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(&vgdev->display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 772a5a3b0ce1a..18e8fcad6690b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -596,9 +596,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(&vgdev->display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
}
--
2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.9 18/33] vdpasim: fix "mac_pton" undefined error
From: Laurent Vivier [ Upstream commit a312db697cb05dfa781848afe8585a1e1f2a5a99 ] ERROR: modpost: "mac_pton" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! mac_pton() is defined in lib/net_utils.c and is not built if NET is not set. Select GENERIC_NET_UTILS as vdpasim doesn't depend on NET. Reported-by: kernel test robot Signed-off-by: Laurent Vivier Link: https://lore.kernel.org/r/20201113155706.599434-1-lviv...@redhat.com Signed-off-by: Michael S. Tsirkin Acked-by: Randy Dunlap # build-tested Signed-off-by: Sasha Levin --- drivers/vdpa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig index d7d32b6561021..358f6048dd3ce 100644 --- a/drivers/vdpa/Kconfig +++ b/drivers/vdpa/Kconfig @@ -13,6 +13,7 @@ config VDPA_SIM depends on RUNTIME_TESTING_MENU && HAS_DMA select DMA_OPS select VHOST_RING + select GENERIC_NET_UTILS default n help vDPA networking device simulator which loop TX traffic back -- 2.27.0 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.9 19/33] vhost: add helper to check if a vq has been setup
From: Mike Christie
[ Upstream commit 6bcf34224ac1e94103797fd68b9836061762f2b2 ]
This adds a helper check if a vq has been setup. The next patches
will use this when we move the vhost scsi cmd preallocation from per
session to per vq. In the per vq case, we only want to allocate cmds
for vqs that have actually been setup and not for all the possible
vqs.
Signed-off-by: Mike Christie
Link:
https://lore.kernel.org/r/1604986403-4931-2-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Jason Wang
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/vhost.c | 6 ++
drivers/vhost/vhost.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 9ad45e1d27f0f..23e7b2d624511 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -305,6 +305,12 @@ static void vhost_vring_call_reset(struct vhost_vring_call
*call_ctx)
spin_lock_init(&call_ctx->ctx_lock);
}
+bool vhost_vq_is_setup(struct vhost_virtqueue *vq)
+{
+ return vq->avail && vq->desc && vq->used && vhost_vq_access_ok(vq);
+}
+EXPORT_SYMBOL_GPL(vhost_vq_is_setup);
+
static void vhost_vq_reset(struct vhost_dev *dev,
struct vhost_virtqueue *vq)
{
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 9032d3c2a9f48..3d30b3da7bcf5 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -190,6 +190,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *,
struct vhost_log *log, unsigned int *log_num);
void vhost_discard_vq_desc(struct vhost_virtqueue *, int n);
+bool vhost_vq_is_setup(struct vhost_virtqueue *vq);
int vhost_vq_init_access(struct vhost_virtqueue *);
int vhost_add_used(struct vhost_virtqueue *, unsigned int head, int len);
int vhost_add_used_n(struct vhost_virtqueue *, struct vring_used_elem *heads,
--
2.27.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.9 21/33] vhost scsi: fix cmd completion race
From: Mike Christie
[ Upstream commit 47a3565e8bb14ec48a75b48daf57aa830e2691f8 ]
We might not do the final se_cmd put from vhost_scsi_complete_cmd_work.
When the last put happens a little later then we could race where
vhost_scsi_complete_cmd_work does vhost_signal, the guest runs and sends
more IO, and vhost_scsi_handle_vq runs but does not find any free cmds.
This patch has us delay completing the cmd until the last lio core ref
is dropped. We then know that once we signal to the guest that the cmd
is completed that if it queues a new command it will find a free cmd.
Signed-off-by: Mike Christie
Reviewed-by: Maurizio Lombardi
Link:
https://lore.kernel.org/r/1604986403-4931-4-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 42 +++---
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index e31339be7dd78..5d8850f5aef16 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -322,7 +322,7 @@ static u32 vhost_scsi_tpg_get_inst_index(struct
se_portal_group *se_tpg)
return 1;
}
-static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
+static void vhost_scsi_release_cmd_res(struct se_cmd *se_cmd)
{
struct vhost_scsi_cmd *tv_cmd = container_of(se_cmd,
struct vhost_scsi_cmd, tvc_se_cmd);
@@ -344,6 +344,16 @@ static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
vhost_scsi_put_inflight(inflight);
}
+static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
+{
+ struct vhost_scsi_cmd *cmd = container_of(se_cmd,
+ struct vhost_scsi_cmd, tvc_se_cmd);
+ struct vhost_scsi *vs = cmd->tvc_vhost;
+
+ llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
+ vhost_work_queue(&vs->dev, &vs->vs_completion_work);
+}
+
static u32 vhost_scsi_sess_get_index(struct se_session *se_sess)
{
return 0;
@@ -366,28 +376,15 @@ static int vhost_scsi_get_cmd_state(struct se_cmd *se_cmd)
return 0;
}
-static void vhost_scsi_complete_cmd(struct vhost_scsi_cmd *cmd)
-{
- struct vhost_scsi *vs = cmd->tvc_vhost;
-
- llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
-
- vhost_work_queue(&vs->dev, &vs->vs_completion_work);
-}
-
static int vhost_scsi_queue_data_in(struct se_cmd *se_cmd)
{
- struct vhost_scsi_cmd *cmd = container_of(se_cmd,
- struct vhost_scsi_cmd, tvc_se_cmd);
- vhost_scsi_complete_cmd(cmd);
+ transport_generic_free_cmd(se_cmd, 0);
return 0;
}
static int vhost_scsi_queue_status(struct se_cmd *se_cmd)
{
- struct vhost_scsi_cmd *cmd = container_of(se_cmd,
- struct vhost_scsi_cmd, tvc_se_cmd);
- vhost_scsi_complete_cmd(cmd);
+ transport_generic_free_cmd(se_cmd, 0);
return 0;
}
@@ -433,15 +430,6 @@ vhost_scsi_allocate_evt(struct vhost_scsi *vs,
return evt;
}
-static void vhost_scsi_free_cmd(struct vhost_scsi_cmd *cmd)
-{
- struct se_cmd *se_cmd = &cmd->tvc_se_cmd;
-
- /* TODO locking against target/backend threads? */
- transport_generic_free_cmd(se_cmd, 0);
-
-}
-
static int vhost_scsi_check_stop_free(struct se_cmd *se_cmd)
{
return target_put_sess_cmd(se_cmd);
@@ -560,7 +548,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work
*work)
} else
pr_err("Faulted on virtio_scsi_cmd_resp\n");
- vhost_scsi_free_cmd(cmd);
+ vhost_scsi_release_cmd_res(se_cmd);
}
vq = -1;
@@ -1091,7 +1079,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
&prot_iter, exp_data_len,
&data_iter))) {
vq_err(vq, "Failed to map iov to sgl\n");
- vhost_scsi_release_cmd(&cmd->tvc_se_cmd);
+ vhost_scsi_release_cmd_res(&cmd->tvc_se_cmd);
goto err;
}
}
--
2.27.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.9 20/33] vhost scsi: alloc cmds per vq instead of session
From: Mike Christie
[ Upstream commit 25b98b64e28423b0769313dcaf96423836b1f93d ]
We currently are limited to 256 cmds per session. This leads to problems
where if the user has increased virtqueue_size to more than 2 or
cmd_per_lun to more than 256 vhost_scsi_get_tag can fail and the guest
will get IO errors.
This patch moves the cmd allocation to per vq so we can easily match
whatever the user has specified for num_queues and
virtqueue_size/cmd_per_lun. It also makes it easier to control how much
memory we preallocate. For cases, where perf is not as important and
we can use the current defaults (1 vq and 128 cmds per vq) memory use
from preallocate cmds is cut in half. For cases, where we are willing
to use more memory for higher perf, cmd mem use will now increase as
the num queues and queue depth increases.
Signed-off-by: Mike Christie
Link:
https://lore.kernel.org/r/1604986403-4931-3-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Maurizio Lombardi
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 207 ++-
1 file changed, 128 insertions(+), 79 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index b22adf03f5842..e31339be7dd78 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -52,7 +52,6 @@
#define VHOST_SCSI_VERSION "v0.1"
#define VHOST_SCSI_NAMELEN 256
#define VHOST_SCSI_MAX_CDB_SIZE 32
-#define VHOST_SCSI_DEFAULT_TAGS 256
#define VHOST_SCSI_PREALLOC_SGLS 2048
#define VHOST_SCSI_PREALLOC_UPAGES 2048
#define VHOST_SCSI_PREALLOC_PROT_SGLS 2048
@@ -189,6 +188,9 @@ struct vhost_scsi_virtqueue {
* Writers must also take dev mutex and flush under it.
*/
int inflight_idx;
+ struct vhost_scsi_cmd *scsi_cmds;
+ struct sbitmap scsi_tags;
+ int max_cmds;
};
struct vhost_scsi {
@@ -324,7 +326,9 @@ static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
{
struct vhost_scsi_cmd *tv_cmd = container_of(se_cmd,
struct vhost_scsi_cmd, tvc_se_cmd);
- struct se_session *se_sess = tv_cmd->tvc_nexus->tvn_se_sess;
+ struct vhost_scsi_virtqueue *svq = container_of(tv_cmd->tvc_vq,
+ struct vhost_scsi_virtqueue, vq);
+ struct vhost_scsi_inflight *inflight = tv_cmd->inflight;
int i;
if (tv_cmd->tvc_sgl_count) {
@@ -336,8 +340,8 @@ static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
put_page(sg_page(&tv_cmd->tvc_prot_sgl[i]));
}
- vhost_scsi_put_inflight(tv_cmd->inflight);
- target_free_tag(se_sess, se_cmd);
+ sbitmap_clear_bit(&svq->scsi_tags, se_cmd->map_tag);
+ vhost_scsi_put_inflight(inflight);
}
static u32 vhost_scsi_sess_get_index(struct se_session *se_sess)
@@ -566,31 +570,31 @@ static void vhost_scsi_complete_cmd_work(struct
vhost_work *work)
}
static struct vhost_scsi_cmd *
-vhost_scsi_get_tag(struct vhost_virtqueue *vq, struct vhost_scsi_tpg *tpg,
+vhost_scsi_get_cmd(struct vhost_virtqueue *vq, struct vhost_scsi_tpg *tpg,
unsigned char *cdb, u64 scsi_tag, u16 lun, u8 task_attr,
u32 exp_data_len, int data_direction)
{
+ struct vhost_scsi_virtqueue *svq = container_of(vq,
+ struct vhost_scsi_virtqueue, vq);
struct vhost_scsi_cmd *cmd;
struct vhost_scsi_nexus *tv_nexus;
- struct se_session *se_sess;
struct scatterlist *sg, *prot_sg;
struct page **pages;
- int tag, cpu;
+ int tag;
tv_nexus = tpg->tpg_nexus;
if (!tv_nexus) {
pr_err("Unable to locate active struct vhost_scsi_nexus\n");
return ERR_PTR(-EIO);
}
- se_sess = tv_nexus->tvn_se_sess;
- tag = sbitmap_queue_get(&se_sess->sess_tag_pool, &cpu);
+ tag = sbitmap_get(&svq->scsi_tags, 0, false);
if (tag < 0) {
pr_err("Unable to obtain tag for vhost_scsi_cmd\n");
return ERR_PTR(-ENOMEM);
}
- cmd = &((struct vhost_scsi_cmd *)se_sess->sess_cmd_map)[tag];
+ cmd = &svq->scsi_cmds[tag];
sg = cmd->tvc_sgl;
prot_sg = cmd->tvc_prot_sgl;
pages = cmd->tvc_upages;
@@ -599,7 +603,6 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq, struct
vhost_scsi_tpg *tpg,
cmd->tvc_prot_sgl = prot_sg;
cmd->tvc_upages = pages;
cmd->tvc_se_cmd.map_tag = tag;
- cmd->tvc_se_cmd.map_cpu = cpu;
cmd->tvc_tag = scsi_tag;
cmd->tvc_lun = lun;
cmd->tvc_task_attr = task_attr;
@@ -1065,11 +1068,11 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
scsi_command_size(cdb),
VHOST_SCSI_MA
[PATCH AUTOSEL 5.9 23/33] vhost scsi: Add support for LUN resets.
From: Mike Christie
[ Upstream commit efd838fec17bd8756da852a435800a7e6281bfbc ]
In newer versions of virtio-scsi we just reset the timer when an a
command times out, so TMFs are never sent for the cmd time out case.
However, in older kernels and for the TMF inject cases, we can still get
resets and we end up just failing immediately so the guest might see the
device get offlined and IO errors.
For the older kernel cases, we want the same end result as the
modern virtio-scsi driver where we let the lower levels fire their error
handling and handle the problem. And at the upper levels we want to
wait. This patch ties the LUN reset handling into the LIO TMF code which
will just wait for outstanding commands to complete like we are doing in
the modern virtio-scsi case.
Note: I did not handle the ABORT case to keep this simple. For ABORTs
LIO just waits on the cmd like how it does for the RESET case. If
an ABORT fails, the guest OS ends up escalating to LUN RESET, so in
the end we get the same behavior where we wait on the outstanding
cmds.
Signed-off-by: Mike Christie
Link:
https://lore.kernel.org/r/1604986403-4931-6-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 147 +++
1 file changed, 134 insertions(+), 13 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index ed7dc6b998f65..f22fce5498626 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -139,6 +139,7 @@ struct vhost_scsi_tpg {
struct se_portal_group se_tpg;
/* Pointer back to vhost_scsi, protected by tv_tpg_mutex */
struct vhost_scsi *vhost_scsi;
+ struct list_head tmf_queue;
};
struct vhost_scsi_tport {
@@ -211,6 +212,20 @@ struct vhost_scsi {
int vs_events_nr; /* num of pending events, protected by vq->mutex */
};
+struct vhost_scsi_tmf {
+ struct vhost_work vwork;
+ struct vhost_scsi_tpg *tpg;
+ struct vhost_scsi *vhost;
+ struct vhost_scsi_virtqueue *svq;
+ struct list_head queue_entry;
+
+ struct se_cmd se_cmd;
+ struct vhost_scsi_inflight *inflight;
+ struct iovec resp_iov;
+ int in_iovs;
+ int vq_desc;
+};
+
/*
* Context for processing request and control queue operations.
*/
@@ -344,14 +359,32 @@ static void vhost_scsi_release_cmd_res(struct se_cmd
*se_cmd)
vhost_scsi_put_inflight(inflight);
}
+static void vhost_scsi_release_tmf_res(struct vhost_scsi_tmf *tmf)
+{
+ struct vhost_scsi_tpg *tpg = tmf->tpg;
+ struct vhost_scsi_inflight *inflight = tmf->inflight;
+
+ mutex_lock(&tpg->tv_tpg_mutex);
+ list_add_tail(&tpg->tmf_queue, &tmf->queue_entry);
+ mutex_unlock(&tpg->tv_tpg_mutex);
+ vhost_scsi_put_inflight(inflight);
+}
+
static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
{
- struct vhost_scsi_cmd *cmd = container_of(se_cmd,
+ if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB) {
+ struct vhost_scsi_tmf *tmf = container_of(se_cmd,
+ struct vhost_scsi_tmf, se_cmd);
+
+ vhost_work_queue(&tmf->vhost->dev, &tmf->vwork);
+ } else {
+ struct vhost_scsi_cmd *cmd = container_of(se_cmd,
struct vhost_scsi_cmd, tvc_se_cmd);
- struct vhost_scsi *vs = cmd->tvc_vhost;
+ struct vhost_scsi *vs = cmd->tvc_vhost;
- llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
- vhost_work_queue(&vs->dev, &vs->vs_completion_work);
+ llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
+ vhost_work_queue(&vs->dev, &vs->vs_completion_work);
+ }
}
static u32 vhost_scsi_sess_get_index(struct se_session *se_sess)
@@ -390,7 +423,10 @@ static int vhost_scsi_queue_status(struct se_cmd *se_cmd)
static void vhost_scsi_queue_tm_rsp(struct se_cmd *se_cmd)
{
- return;
+ struct vhost_scsi_tmf *tmf = container_of(se_cmd, struct vhost_scsi_tmf,
+ se_cmd);
+
+ transport_generic_free_cmd(&tmf->se_cmd, 0);
}
static void vhost_scsi_aborted_task(struct se_cmd *se_cmd)
@@ -1120,9 +1156,9 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
}
static void
-vhost_scsi_send_tmf_reject(struct vhost_scsi *vs,
- struct vhost_virtqueue *vq,
- struct vhost_scsi_ctx *vc)
+vhost_scsi_send_tmf_resp(struct vhost_scsi *vs, struct vhost_virtqueue *vq,
+int in_iovs, int vq_desc, struct iovec *resp_iov,
+int tmf_resp_code)
{
struct virtio_scsi_ctrl_tmf_resp rsp;
struct iov_iter iov_iter;
@@ -
[PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper
From: Mike Christie
[ Upstream commit 18f1becb6948cd411fd01968a0a54af63732e73c ]
Move code to parse lun from req's lun_buf to helper, so tmf code
can use it in the next patch.
Signed-off-by: Mike Christie
Reviewed-by: Paolo Bonzini
Acked-by: Jason Wang
Link:
https://lore.kernel.org/r/1604986403-4931-5-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 5d8850f5aef16..ed7dc6b998f65 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -898,6 +898,11 @@ vhost_scsi_get_req(struct vhost_virtqueue *vq, struct
vhost_scsi_ctx *vc,
return ret;
}
+static u16 vhost_buf_to_lun(u8 *lun_buf)
+{
+ return ((lun_buf[2] << 8) | lun_buf[3]) & 0x3FFF;
+}
+
static void
vhost_scsi_handle_vq(struct vhost_scsi *vs, struct vhost_virtqueue *vq)
{
@@ -1036,12 +1041,12 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
tag = vhost64_to_cpu(vq, v_req_pi.tag);
task_attr = v_req_pi.task_attr;
cdb = &v_req_pi.cdb[0];
- lun = ((v_req_pi.lun[2] << 8) | v_req_pi.lun[3]) &
0x3FFF;
+ lun = vhost_buf_to_lun(v_req_pi.lun);
} else {
tag = vhost64_to_cpu(vq, v_req.tag);
task_attr = v_req.task_attr;
cdb = &v_req.cdb[0];
- lun = ((v_req.lun[2] << 8) | v_req.lun[3]) & 0x3FFF;
+ lun = vhost_buf_to_lun(v_req.lun);
}
/*
* Check that the received CDB size does not exceeded our
--
2.27.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 16/23] vhost scsi: add lun parser helper
From: Mike Christie
[ Upstream commit 18f1becb6948cd411fd01968a0a54af63732e73c ]
Move code to parse lun from req's lun_buf to helper, so tmf code
can use it in the next patch.
Signed-off-by: Mike Christie
Reviewed-by: Paolo Bonzini
Acked-by: Jason Wang
Link:
https://lore.kernel.org/r/1604986403-4931-5-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 98c484149ac7f..6b816b3a65ea7 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -895,6 +895,11 @@ vhost_scsi_get_req(struct vhost_virtqueue *vq, struct
vhost_scsi_ctx *vc,
return ret;
}
+static u16 vhost_buf_to_lun(u8 *lun_buf)
+{
+ return ((lun_buf[2] << 8) | lun_buf[3]) & 0x3FFF;
+}
+
static void
vhost_scsi_handle_vq(struct vhost_scsi *vs, struct vhost_virtqueue *vq)
{
@@ -1033,12 +1038,12 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
tag = vhost64_to_cpu(vq, v_req_pi.tag);
task_attr = v_req_pi.task_attr;
cdb = &v_req_pi.cdb[0];
- lun = ((v_req_pi.lun[2] << 8) | v_req_pi.lun[3]) &
0x3FFF;
+ lun = vhost_buf_to_lun(v_req_pi.lun);
} else {
tag = vhost64_to_cpu(vq, v_req.tag);
task_attr = v_req.task_attr;
cdb = &v_req.cdb[0];
- lun = ((v_req.lun[2] << 8) | v_req.lun[3]) & 0x3FFF;
+ lun = vhost_buf_to_lun(v_req.lun);
}
/*
* Check that the received CDB size does not exceeded our
--
2.27.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 17/23] vhost scsi: Add support for LUN resets.
From: Mike Christie
[ Upstream commit efd838fec17bd8756da852a435800a7e6281bfbc ]
In newer versions of virtio-scsi we just reset the timer when an a
command times out, so TMFs are never sent for the cmd time out case.
However, in older kernels and for the TMF inject cases, we can still get
resets and we end up just failing immediately so the guest might see the
device get offlined and IO errors.
For the older kernel cases, we want the same end result as the
modern virtio-scsi driver where we let the lower levels fire their error
handling and handle the problem. And at the upper levels we want to
wait. This patch ties the LUN reset handling into the LIO TMF code which
will just wait for outstanding commands to complete like we are doing in
the modern virtio-scsi case.
Note: I did not handle the ABORT case to keep this simple. For ABORTs
LIO just waits on the cmd like how it does for the RESET case. If
an ABORT fails, the guest OS ends up escalating to LUN RESET, so in
the end we get the same behavior where we wait on the outstanding
cmds.
Signed-off-by: Mike Christie
Link:
https://lore.kernel.org/r/1604986403-4931-6-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 147 +++
1 file changed, 134 insertions(+), 13 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 6b816b3a65ea7..e37362fd2e935 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -140,6 +140,7 @@ struct vhost_scsi_tpg {
struct se_portal_group se_tpg;
/* Pointer back to vhost_scsi, protected by tv_tpg_mutex */
struct vhost_scsi *vhost_scsi;
+ struct list_head tmf_queue;
};
struct vhost_scsi_tport {
@@ -209,6 +210,20 @@ struct vhost_scsi {
int vs_events_nr; /* num of pending events, protected by vq->mutex */
};
+struct vhost_scsi_tmf {
+ struct vhost_work vwork;
+ struct vhost_scsi_tpg *tpg;
+ struct vhost_scsi *vhost;
+ struct vhost_scsi_virtqueue *svq;
+ struct list_head queue_entry;
+
+ struct se_cmd se_cmd;
+ struct vhost_scsi_inflight *inflight;
+ struct iovec resp_iov;
+ int in_iovs;
+ int vq_desc;
+};
+
/*
* Context for processing request and control queue operations.
*/
@@ -340,14 +355,32 @@ static void vhost_scsi_release_cmd_res(struct se_cmd
*se_cmd)
target_free_tag(se_sess, se_cmd);
}
+static void vhost_scsi_release_tmf_res(struct vhost_scsi_tmf *tmf)
+{
+ struct vhost_scsi_tpg *tpg = tmf->tpg;
+ struct vhost_scsi_inflight *inflight = tmf->inflight;
+
+ mutex_lock(&tpg->tv_tpg_mutex);
+ list_add_tail(&tpg->tmf_queue, &tmf->queue_entry);
+ mutex_unlock(&tpg->tv_tpg_mutex);
+ vhost_scsi_put_inflight(inflight);
+}
+
static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
{
- struct vhost_scsi_cmd *cmd = container_of(se_cmd,
+ if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB) {
+ struct vhost_scsi_tmf *tmf = container_of(se_cmd,
+ struct vhost_scsi_tmf, se_cmd);
+
+ vhost_work_queue(&tmf->vhost->dev, &tmf->vwork);
+ } else {
+ struct vhost_scsi_cmd *cmd = container_of(se_cmd,
struct vhost_scsi_cmd, tvc_se_cmd);
- struct vhost_scsi *vs = cmd->tvc_vhost;
+ struct vhost_scsi *vs = cmd->tvc_vhost;
- llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
- vhost_work_queue(&vs->dev, &vs->vs_completion_work);
+ llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
+ vhost_work_queue(&vs->dev, &vs->vs_completion_work);
+ }
}
static u32 vhost_scsi_sess_get_index(struct se_session *se_sess)
@@ -386,7 +419,10 @@ static int vhost_scsi_queue_status(struct se_cmd *se_cmd)
static void vhost_scsi_queue_tm_rsp(struct se_cmd *se_cmd)
{
- return;
+ struct vhost_scsi_tmf *tmf = container_of(se_cmd, struct vhost_scsi_tmf,
+ se_cmd);
+
+ transport_generic_free_cmd(&tmf->se_cmd, 0);
}
static void vhost_scsi_aborted_task(struct se_cmd *se_cmd)
@@ -1117,9 +1153,9 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
}
static void
-vhost_scsi_send_tmf_reject(struct vhost_scsi *vs,
- struct vhost_virtqueue *vq,
- struct vhost_scsi_ctx *vc)
+vhost_scsi_send_tmf_resp(struct vhost_scsi *vs, struct vhost_virtqueue *vq,
+int in_iovs, int vq_desc, struct iovec *resp_iov,
+int tmf_resp_code)
{
struct virtio_scsi_ctrl_tmf_resp rsp;
struct iov_iter iov_iter;
@@ -
[PATCH AUTOSEL 5.4 15/23] vhost scsi: fix cmd completion race
From: Mike Christie
[ Upstream commit 47a3565e8bb14ec48a75b48daf57aa830e2691f8 ]
We might not do the final se_cmd put from vhost_scsi_complete_cmd_work.
When the last put happens a little later then we could race where
vhost_scsi_complete_cmd_work does vhost_signal, the guest runs and sends
more IO, and vhost_scsi_handle_vq runs but does not find any free cmds.
This patch has us delay completing the cmd until the last lio core ref
is dropped. We then know that once we signal to the guest that the cmd
is completed that if it queues a new command it will find a free cmd.
Signed-off-by: Mike Christie
Reviewed-by: Maurizio Lombardi
Link:
https://lore.kernel.org/r/1604986403-4931-4-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
---
drivers/vhost/scsi.c | 42 +++---
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index f63f84a257256..98c484149ac7f 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -320,7 +320,7 @@ static u32 vhost_scsi_tpg_get_inst_index(struct
se_portal_group *se_tpg)
return 1;
}
-static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
+static void vhost_scsi_release_cmd_res(struct se_cmd *se_cmd)
{
struct vhost_scsi_cmd *tv_cmd = container_of(se_cmd,
struct vhost_scsi_cmd, tvc_se_cmd);
@@ -340,6 +340,16 @@ static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
target_free_tag(se_sess, se_cmd);
}
+static void vhost_scsi_release_cmd(struct se_cmd *se_cmd)
+{
+ struct vhost_scsi_cmd *cmd = container_of(se_cmd,
+ struct vhost_scsi_cmd, tvc_se_cmd);
+ struct vhost_scsi *vs = cmd->tvc_vhost;
+
+ llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
+ vhost_work_queue(&vs->dev, &vs->vs_completion_work);
+}
+
static u32 vhost_scsi_sess_get_index(struct se_session *se_sess)
{
return 0;
@@ -362,28 +372,15 @@ static int vhost_scsi_get_cmd_state(struct se_cmd *se_cmd)
return 0;
}
-static void vhost_scsi_complete_cmd(struct vhost_scsi_cmd *cmd)
-{
- struct vhost_scsi *vs = cmd->tvc_vhost;
-
- llist_add(&cmd->tvc_completion_list, &vs->vs_completion_list);
-
- vhost_work_queue(&vs->dev, &vs->vs_completion_work);
-}
-
static int vhost_scsi_queue_data_in(struct se_cmd *se_cmd)
{
- struct vhost_scsi_cmd *cmd = container_of(se_cmd,
- struct vhost_scsi_cmd, tvc_se_cmd);
- vhost_scsi_complete_cmd(cmd);
+ transport_generic_free_cmd(se_cmd, 0);
return 0;
}
static int vhost_scsi_queue_status(struct se_cmd *se_cmd)
{
- struct vhost_scsi_cmd *cmd = container_of(se_cmd,
- struct vhost_scsi_cmd, tvc_se_cmd);
- vhost_scsi_complete_cmd(cmd);
+ transport_generic_free_cmd(se_cmd, 0);
return 0;
}
@@ -429,15 +426,6 @@ vhost_scsi_allocate_evt(struct vhost_scsi *vs,
return evt;
}
-static void vhost_scsi_free_cmd(struct vhost_scsi_cmd *cmd)
-{
- struct se_cmd *se_cmd = &cmd->tvc_se_cmd;
-
- /* TODO locking against target/backend threads? */
- transport_generic_free_cmd(se_cmd, 0);
-
-}
-
static int vhost_scsi_check_stop_free(struct se_cmd *se_cmd)
{
return target_put_sess_cmd(se_cmd);
@@ -556,7 +544,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work
*work)
} else
pr_err("Faulted on virtio_scsi_cmd_resp\n");
- vhost_scsi_free_cmd(cmd);
+ vhost_scsi_release_cmd_res(se_cmd);
}
vq = -1;
@@ -1088,7 +1076,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
&prot_iter, exp_data_len,
&data_iter))) {
vq_err(vq, "Failed to map iov to sgl\n");
- vhost_scsi_release_cmd(&cmd->tvc_se_cmd);
+ vhost_scsi_release_cmd_res(&cmd->tvc_se_cmd);
goto err;
}
}
--
2.27.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper
On Wed, Nov 25, 2020 at 06:48:21PM +0100, Paolo Bonzini wrote:
On 25/11/20 16:35, Sasha Levin wrote:
From: Mike Christie
[ Upstream commit 18f1becb6948cd411fd01968a0a54af63732e73c ]
Move code to parse lun from req's lun_buf to helper, so tmf code
can use it in the next patch.
Signed-off-by: Mike Christie
Reviewed-by: Paolo Bonzini
Acked-by: Jason Wang
Link:
https://lore.kernel.org/r/1604986403-4931-5-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
This doesn't seem like stable material, does it?
It went in as a dependency for efd838fec17b ("vhost scsi: Add support
for LUN resets."), which is the next patch.
--
Thanks,
Sasha
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper
On Wed, Nov 25, 2020 at 07:08:54PM +0100, Paolo Bonzini wrote:
On 25/11/20 19:01, Sasha Levin wrote:
On Wed, Nov 25, 2020 at 06:48:21PM +0100, Paolo Bonzini wrote:
On 25/11/20 16:35, Sasha Levin wrote:
From: Mike Christie
[ Upstream commit 18f1becb6948cd411fd01968a0a54af63732e73c ]
Move code to parse lun from req's lun_buf to helper, so tmf code
can use it in the next patch.
Signed-off-by: Mike Christie
Reviewed-by: Paolo Bonzini
Acked-by: Jason Wang
Link:
https://lore.kernel.org/r/1604986403-4931-5-git-send-email-michael.chris...@oracle.com
Signed-off-by: Michael S. Tsirkin
Acked-by: Stefan Hajnoczi
Signed-off-by: Sasha Levin
This doesn't seem like stable material, does it?
It went in as a dependency for efd838fec17b ("vhost scsi: Add support
for LUN resets."), which is the next patch.
Which doesn't seem to be suitable for stable either... Patch 3/5 in
Why not? It was sent as a fix to Linus.
the series might be (vhost scsi: fix cmd completion race), so I can
understand including 1/5 and 2/5 just in case, but not the rest. Does
the bot not understand diffstats?
Not on their own, no. What's wrong with the diffstats?
--
Thanks,
Sasha
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper
On Sun, Nov 29, 2020 at 06:34:01PM +0100, Paolo Bonzini wrote: On 29/11/20 05:13, Sasha Levin wrote: Which doesn't seem to be suitable for stable either... Patch 3/5 in Why not? It was sent as a fix to Linus. Dunno, 120 lines of new code? Even if it's okay for an rc, I don't see why it is would be backported to stable releases and release it without any kind of testing. Maybe for 5.9 the chances of breaking Lines of code is not everything. If you think that this needs additional testing then that's fine and we can drop it, but not picking up a fix just because it's 120 lines is not something we'd do. things are low, but stuff like locking rules might have changed since older releases like 5.4 or 4.19. The autoselection bot does not know that, it basically crosses fingers that these larger-scale changes cause the patches not to apply or compile anymore. Plus all the testing we have for the stable trees, yes. It goes beyond just compiling at this point. Your very own co-workers (https://cki-project.org/) are pushing hard on this effort around stable kernel testing, and statements like these aren't helping anyone. If on the other hand, you'd like to see specific KVM/virtio/etc tests as part of the stable release process, we should all work together to make sure they're included in the current test suite. Maybe it's just me, but the whole "autoselect stable patches" and release them is very suspicious. You are basically crossing fingers Historically autoselected patches were later fixed/reverted at a lower ratio than patches tagged with a stable tag. I *think* that it's because they get a longer review cycle than some of the stable tagged patches. and are ready to release any kind of untested crap, because you do not trust maintainers of marking stable patches right. Only then, when a It's not that I don't trust - some folks forget, or not realize that something should go in stable. We're all humans. This is to complement the work done by maintainers, not replace it. backport is broken, it's maintainers who get the blame and have to fix it. What blame? Who's blaming who? Personally I don't care because I have asked you to opt KVM out of autoselection, but this is the opposite of what Greg brags about when he touts the virtues of the upstream stable process over vendor kernels. What, that we try and include all fixes rather than the ones I'm paid to pick up? If you have a vendor you pay $$$ to, then yes - you're probably better off with a vendor kernel. This is actually in line (I think) with Greg's views on this (http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/). -- Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper
On Mon, Nov 30, 2020 at 03:00:13PM +0100, Paolo Bonzini wrote: On 30/11/20 14:57, Greg KH wrote: Every patch should be "fixing a real issue"---even a new feature. But the larger the patch, the more the submitters and maintainers should be trusted rather than a bot. The line between feature and bugfix_sometimes_ is blurry, I would say that in this case it's not, and it makes me question how the bot decided that this patch would be acceptable for stable (which AFAIK is not something that can be answered). I thought that earlier Sasha said that this patch was needed as a prerequisite patch for a later fix, right? If not, sorry, I've lost the train of thought in this thread... Yeah---sorry I am replying to 22/33 but referring to 23/33, which is the one that in my opinion should not be blindly accepted for stable kernels without the agreement of the submitter or maintainer. But it's not "blindly", right? I've sent this review mail over a week ago, and if it goes into the queue there will be at least two more emails going out to the author/maintainers. During all this time it gets tested by various entities who do things that go beyond simple boot testing. I'd argue that the backports we push in the stable tree sometimes get tested and reviewed better than the commits that land upstream. -- Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper
On Mon, Nov 30, 2020 at 09:33:46AM +0100, Paolo Bonzini wrote: On 29/11/20 22:06, Sasha Levin wrote: Plus all the testing we have for the stable trees, yes. It goes beyond just compiling at this point. Your very own co-workers (https://cki-project.org/) are pushing hard on this effort around stable kernel testing, and statements like these aren't helping anyone. I am not aware of any public CI being done _at all_ done on vhost-scsi, by CKI or everyone else. So autoselection should be done only on subsystems that have very high coverage in CI. Where can I find a testsuite for virtio/vhost? I see one for KVM, but where is the one that the maintainers of virtio/vhost run on patches that come in? -- Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
