similar to: [vhost:linux-next 12/19] drivers/vhost/vhost.h:196:22: error: field 'mmu_notifier' has incomplete type

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. > >

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace(qemu) implementation of DMA remapping. The idea is simple, cache the translation in a software device IOTLB (which was implemented as interval tree) in vhost and use vhost_net file descriptor for reporting IOTLB miss and IOTLB update/invalidation. When vhost meets an IOTLB miss, 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

On Tue, Mar 07, 2017 at 10:47:05AM +0100, Guillaume Missonnier wrote: > Move vhost.h to include/linux to allow vhost driver out-of-tree compilation. > Currently, this cannot be done properly because the vhost header file is in > driver/vhost. > > To distribute a new vhost driver before it is included in the kernel tree, > we need to package it using kmod, dkms, ..., and to

From: Jason Gunthorpe <jgg at mellanox.com> Now that we have KERNEL_HEADER_TEST all headers are generally compile tested, so relying on makefile tricks to avoid compiling code that depends on CONFIG_MMU_NOTIFIER is more annoying. Instead follow the usual pattern and provide most of the header with only the functions stubbed out when CONFIG_MMU_NOTIFIER is disabled. This ensures code

From: Jason Gunthorpe <jgg at mellanox.com> Now that we have KERNEL_HEADER_TEST all headers are generally compile tested, so relying on makefile tricks to avoid compiling code that depends on CONFIG_MMU_NOTIFIER is more annoying. Instead follow the usual pattern and provide most of the header with only the functions stubbed out when CONFIG_MMU_NOTIFIER is disabled. This ensures code

Device drivers may or may not have a convenient range based data structure to look up and find intervals that are registered with the mmu interval notifiers. Rather than forcing drivers to duplicate the interval tree, provide an API to look up intervals that are registered and accessor functions to return the start and last address of the interval. Signed-off-by: Ralph Campbell <rcampbell at

On 10/28/19 1:10 PM, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Now that we have KERNEL_HEADER_TEST all headers are generally compile > tested, so relying on makefile tricks to avoid compiling code that depends > on CONFIG_MMU_NOTIFIER is more annoying. > > Instead follow the usual pattern and provide most of the header with only > the

mmu_interval_notifier_insert() can't be called safely from inside the invalidate() callback because it can acquire the mmap_sem lock which might already be held. Insertion might be needed when the invalidate() callback creates a "hole" in the interval being tracked (i.e., the event type MMU_NOTIFY_UNMAP) and the interval needs to be split in order to continue receiving callbacks for

mmu_interval_notifier_remove() can't be called safely from inside the invalidate() callback because it sleeps waiting for invalidate callbacks to finish. Removals might be needed when the invalidate() callback is for munmap() (i.e., the event type MMU_NOTIFY_UNMAP), and the interval being tracked is no longer needed. Add a new function mmu_interval_notifier_put() which is safe to call from

On Tue, Nov 05, 2019 at 01:23:46PM -0800, John Hubbard wrote: > On 10/28/19 1:10 PM, Jason Gunthorpe wrote: > > From: Jason Gunthorpe <jgg at mellanox.com> > > > > Now that we have KERNEL_HEADER_TEST all headers are generally compile > > tested, so relying on makefile tricks to avoid compiling code that depends > > on CONFIG_MMU_NOTIFIER is more annoying.

I haven't had enough time to fully understand the deferred logic in this change. I spotted one problem, see comments inline. On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Of the 13 users of mmu_notifiers, 8 of them use only > invalidate_range_start/end() and immediately intersect the > mmu_notifier_range with some kind

On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote: >> 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

On Mon, Sep 09, 2019 at 10:18:57AM +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote: > > > This is a rework on the commit 7f466032dc9e ("vhost: access vq > > > metadata through kernel virtual address"). > > > > > > It was noticed that the

On 1/14/20 4:49 AM, Jason Gunthorpe wrote: > On Mon, Jan 13, 2020 at 02:47:01PM -0800, Ralph Campbell wrote: >> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c >> index 47ad9cc89aab..4efecc0f13cb 100644 >> +++ b/mm/mmu_notifier.c >> @@ -1171,6 +1171,39 @@ void mmu_interval_notifier_update(struct mmu_interval_notifier *mni, >> } >>

This patch factors out IOTLB into a dedicated module in order to be reused by other modules like vringh. User may choose to enable the automatic retiring by specifying VHOST_IOTLB_FLAG_RETIRE flag to fit for the case of vhost device IOTLB implementation. Signed-off-by: Jason Wang <jasowang at redhat.com> --- MAINTAINERS | 1 + drivers/vhost/Kconfig | 7 ++

On 11/7/19 12:06 PM, Jason Gunthorpe wrote: ... >> >> Also, it is best moved down to be next to the new MNR structs, so that all the >> MNR stuff is in one group. > > I agree with Jerome, this enum is part of the 'struct > mmu_notifier_range' (ie the description of the invalidation) and it > doesn't really matter that only these new notifiers can be

From: Jason Gunthorpe <jgg at mellanox.com> There is no reason to get the invalidate_range_start() callback via an indirection through hmm_mirror, just register a normal notifier directly. Cc: Ben Skeggs <bskeggs at redhat.com> Cc: dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc: Ralph Campbell <rcampbell at nvidia.com> Signed-off-by: Jason Gunthorpe

On Mon, Jan 13, 2020 at 02:47:01PM -0800, Ralph Campbell wrote: > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c > index 47ad9cc89aab..4efecc0f13cb 100644 > +++ b/mm/mmu_notifier.c > @@ -1171,6 +1171,39 @@ void mmu_interval_notifier_update(struct mmu_interval_notifier *mni, > } > EXPORT_SYMBOL_GPL(mmu_interval_notifier_update); > > +struct mmu_interval_notifier