similar to: [PATCH RFC] vhost: don't use kmap() to log dirty pages

On Mon, May 06, 2019 at 10:23:29PM -0400, Jason Wang wrote: > Vhost log dirty pages directly to a userspace bitmap through GUP and > kmap_atomic() since kernel doesn't have a set_bit_to_user() > helper. This will cause issues for the arch that has virtually tagged > caches. The way to fix is to keep using userspace virtual address. > > Fortunately, futex has a cmpxchg to

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has arch_futex_atomic_op_inuser() which could be used for setting a bit to user. Note there're several

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has arch_futex_atomic_op_inuser() which could be used for setting a bit to user. Note there're several

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has arch_futex_atomic_op_inuser() which could be used for setting a bit to user. Note: - There're archs

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has arch_futex_atomic_op_inuser() which could be used for setting a bit to user. Note: - There're archs

On Mon, May 06, 2019 at 10:23:29PM -0400, Jason Wang wrote: > Note: there're archs (few non popular ones) that don't implement > futex helper, we can't log dirty pages. We can fix them on top or > simply disable LOG_ALL features of vhost. That means vhost now has to depend on HAVE_FUTEX_CMPXCHG to make sure we have a working implementation. > #include

On 2019/5/9 ??9:18, Michael S. Tsirkin wrote: > On Thu, May 09, 2019 at 08:58:00AM -0400, Jason Wang wrote: >> Vhost log dirty pages directly to a userspace bitmap through GUP and >> kmap_atomic() since kernel doesn't have a set_bit_to_user() >> helper. This will cause issues for the arch that has virtually tagged >> caches. The way to fix is to keep using userspace

On 2019/5/9 ??9:18, Michael S. Tsirkin wrote: > On Thu, May 09, 2019 at 08:58:00AM -0400, Jason Wang wrote: >> Vhost log dirty pages directly to a userspace bitmap through GUP and >> kmap_atomic() since kernel doesn't have a set_bit_to_user() >> helper. This will cause issues for the arch that has virtually tagged >> caches. The way to fix is to keep using userspace

On Mon, May 13, 2019 at 01:27:45AM -0400, Jason Wang wrote: > Vhost log dirty pages directly to a userspace bitmap through GUP and > kmap_atomic() since kernel doesn't have a set_bit_to_user() > helper. This will cause issues for the arch that has virtually tagged > caches. The way to fix is to keep using userspace virtual > address. Fortunately, futex has

On Thu, May 09, 2019 at 08:58:00AM -0400, Jason Wang wrote: > Vhost log dirty pages directly to a userspace bitmap through GUP and > kmap_atomic() since kernel doesn't have a set_bit_to_user() > helper. This will cause issues for the arch that has virtually tagged > caches. The way to fix is to keep using userspace virtual > address. Fortunately, futex has

When counting pages we should increase it by 1 instead of VHOST_PAGE_SIZE, and also make log_write() can correctly process the request across pages with write_address not start at page boundary. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 20 +++++++++----------- 1 files changed, 9 insertions(+), 11 deletions(-) diff --git a/drivers/vhost/vhost.c

When counting pages we should increase it by 1 instead of VHOST_PAGE_SIZE, and also make log_write() can correctly process the request across pages with write_address not start at page boundary. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 20 +++++++++----------- 1 files changed, 9 insertions(+), 11 deletions(-) diff --git a/drivers/vhost/vhost.c

From: Jason Wang <jasowang at redhat.com> Date: Mon, 13 May 2019 01:27:45 -0400 > Vhost log dirty pages directly to a userspace bitmap through GUP and > kmap_atomic() since kernel doesn't have a set_bit_to_user() > helper. This will cause issues for the arch that has virtually tagged > caches. The way to fix is to keep using userspace virtual > address. Fortunately, futex

We set dirty bit through setting up kmaps and access them through kernel virtual address, this may result alias in virtually tagged caches that require a dcache flush afterwards. Cc: Christoph Hellwig <hch at infradead.org> Cc: James Bottomley <James.Bottomley at HansenPartnership.com> Cc: Andrea Arcangeli <aarcange at redhat.com> Fixes: 3a4d5c94e9593 ("vhost_net: a

We set dirty bit through setting up kmaps and access them through kernel virtual address, this may result alias in virtually tagged caches that require a dcache flush afterwards. Cc: Christoph Hellwig <hch at infradead.org> Cc: James Bottomley <James.Bottomley at HansenPartnership.com> Cc: Andrea Arcangeli <aarcange at redhat.com> Fixes: 3a4d5c94e9593 ("vhost_net: a

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Mon, 11 Mar 2019 09:59:28 -0400 > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote: >> >> On 2019/3/8 ??10:12, Christoph Hellwig wrote: >> > On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote: >> > > This series tries to access virtqueue metadata through kernel virtual

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Mon, 11 Mar 2019 09:59:28 -0400 > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote: >> >> On 2019/3/8 ??10:12, Christoph Hellwig wrote: >> > On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote: >> > > This series tries to access virtqueue metadata through kernel virtual

xend crashes at startup with following stack trace: ... File "/usr/lib64/python/xen/xend/XendPIF.py", line 68, in linux_get_phy_ifaces phy_ifaces.append((name, int(mtu), bridged_mac)) UnboundLocalError: local variable ''bridged_mac'' referenced before assignment The simple patch attached below prevent the crash, and allow xend to start normally. It seems the crash

Vq log_base is the userspace address of bitmap which has nothing to do with IOTLB. So it needs to be validated unconditionally otherwise we may try use 0 as log_base which may lead to pin pages that will lead unexpected result (e.g trigger BUG_ON() in set_bit_to_user()). Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Reported-by: syzbot+6304bf97ef436580fede at

Vq log_base is the userspace address of bitmap which has nothing to do with IOTLB. So it needs to be validated unconditionally otherwise we may try use 0 as log_base which may lead to pin pages that will lead unexpected result (e.g trigger BUG_ON() in set_bit_to_user()). Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Reported-by: syzbot+6304bf97ef436580fede at