similar to: [PATCH] vhost: It's better to use size_t for the 3rd parameter of vhost_exceeds_weight()

On 2019/9/23 ??5:12, wangxu (AE) wrote: > Hi Michael > > Thanks for your fast reply. > > As the following code, the 2nd branch of iov_iter_advance() does not check if i->count < size, when this happens, i->count -= size may cause len exceed INT_MAX, and then total_len exceed INT_MAX. > > handle_tx_copy() -> > get_tx_bufs(..., &len, ...) -> >

We used to have vhost_exceeds_weight() for vhost-net to: - prevent vhost kthread from hogging the cpu - balance the time spent between TX and RX This function could be useful for vsock and scsi as well. So move it to vhost.c. Device must specify a weight which counts the number of requests, or it can also specific a byte_weight which counts the number of bytes that has been processed.

The return value of mmu_notifier_register() is not checked in vhost_vring_set_num_addr(). This will cause an out of sync between mm and MMU notifier thus a double free. To solve this, introduce a boolean flag to track whether MMU notifier is registered and only do unregistering when it was true. Reported-and-tested-by: syzbot+e58112d71f77113ddb7b at syzkaller.appspotmail.com Fixes: 7f466032dc9e

On Tue, Jul 23, 2019 at 03:57:14AM -0400, Jason Wang wrote: > The return value of mmu_notifier_register() is not checked in > vhost_vring_set_num_addr(). This will cause an out of sync between mm > and MMU notifier thus a double free. To solve this, introduce a > boolean flag to track whether MMU notifier is registered and only do > unregistering when it was true. > >

vDPA device currently relays the eventfd via vhost worker. This is inefficient due the latency of wakeup and scheduling, so this patch tries to introduce a use_worker attribute for the vhost device. When use_worker is not set with vhost_dev_init(), vhost won't try to allocate a worker thread and the vhost_poll will be processed directly in the wakeup function. This help for vDPA since it

On Tue, Oct 22, 2019 at 6:46 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > This patch adds kcov_remote_start()/kcov_remote_stop() annotations to the > vhost_worker() function, which is responsible for processing vhost works. > Since vhost_worker() threads are spawned per vhost device instance > the common kcov handle is used for kcov_remote_start()/stop()

On Wed, Oct 23, 2019 at 3:35 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > On Wed, Oct 23, 2019 at 10:36 AM Dmitry Vyukov <dvyukov at google.com> wrote: > > > > On Tue, Oct 22, 2019 at 6:46 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > > > > > This patch adds kcov_remote_start()/kcov_remote_stop() annotations to the >

This is a rework on the commit 7f466032dc9e ("vhost: access vq metadata through kernel virtual address"). It was noticed that the copy_to/from_user() friends that was used to access virtqueue metdata tends to be very expensive for dataplane implementation like vhost since it involves lots of software checks, speculation barriers, hardware feature toggling (e.g SMAP). The extra cost will

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 15d191a..de544ee 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -479,6 +479,12 @@ static size_t init_iov_iter(struct vhost_virtqueue *vq, struct iov_iter *iter, return

On Mon, 21 May 2018 17:04:23 +0800 Jason wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/net.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 15d191a..de544ee 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -479,6

On 5/31/23 10:15 AM, Mike Christie wrote: >>> rcu would work for your case and for what Jason had requested. >> Yeah, so you already have some patches? >> >> Do you want to send it to solve this problem? >> > Yeah, I'll break them out and send them later today when I can retest > rebased patches. > Just one question. Do you core vhost developers

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set and

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set and

Hi: This series try to prvernt a guest triggerable CPU hogging through vhost kthread. This is done by introducing and checking the weight after each requrest. The patch has been tested with reproducer of vsock and virtio-net. Only compile test is done for vhost-scsi. Please review. This addresses CVE-2019-3900. Jason Wang (4): vhost: introduce vhost_exceeds_weight() vhost_net: fix possible

Hi: This series try to prevent a guest triggerable CPU hogging through vhost kthread. This is done by introducing and checking the weight after each requrest. The patch has been tested with reproducer of vsock and virtio-net. Only compile test is done for vhost-scsi. Please review. This addresses CVE-2019-3900. Changs from V1: - fix user-ater-free in vosck patch Jason Wang (4): vhost:

Hi: This series try to prevent a guest triggerable CPU hogging through vhost kthread. This is done by introducing and checking the weight after each requrest. The patch has been tested with reproducer of vsock and virtio-net. Only compile test is done for vhost-scsi. Please review. This addresses CVE-2019-3900. Changs from V1: - fix user-ater-free in vosck patch Jason Wang (4): vhost:

On Wed, May 31, 2023 at 11:27:12AM -0500, Mike Christie wrote: >On 5/31/23 10:15 AM, Mike Christie wrote: >>>> rcu would work for your case and for what Jason had requested. >>> Yeah, so you already have some patches? >>> >>> Do you want to send it to solve this problem? >>> >> Yeah, I'll break them out and send them later today when I

On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >can race where: >1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >3. vhost_worker_create will set the dev->worker pointer before setting >the worker->vtsk

For vhost-scsi with 3 vqs and a workload like that tries to use those vqs like: fio --filename=/dev/sdb --direct=1 --rw=randrw --bs=4k \ --ioengine=libaio --iodepth=128 --numjobs=3 the single vhost worker thread will become a bottlneck and we are stuck at around 500K IOPs no matter how many jobs, virtqueues, and CPUs are used. To better utilize virtqueues and available CPUs, this patch allows

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: aa5dc31069763f9b1afcfcf2583de258af44d72c commit: eb43203ceabbab75b07a526b59b34bc170e0dc2c [12/19] vhost: access vq metadata through kernel virtual address config: mips-allyesconfig (attached as .config) compiler: mips-linux-gcc (GCC) 7.4.0 reproduce: wget