search for: mmu_range_notifier_insert

...PM -0400, Boris Ostrovsky wrote: >> On 10/28/19 4:10 PM, Jason Gunthorpe wrote: >>> From: Jason Gunthorpe <jgg at mellanox.com> >>> >>> gntdev simply wants to monitor a specific VMA for any notifier events, >>> this can be done straightforwardly using mmu_range_notifier_insert() over >>> the VMA's VA range. >>> >>> The notifier should be attached until the original VMA is destroyed. >>> >>> It is unclear if any of this is even sane, but at least a lot of duplicate >>> code is removed. >> I didn't have a...

...2019 at 12:55:37PM -0400, Boris Ostrovsky wrote: > On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > > From: Jason Gunthorpe <jgg at mellanox.com> > > > > gntdev simply wants to monitor a specific VMA for any notifier events, > > this can be done straightforwardly using mmu_range_notifier_insert() over > > the VMA's VA range. > > > > The notifier should be attached until the original VMA is destroyed. > > > > It is unclear if any of this is even sane, but at least a lot of duplicate > > code is removed. > > I didn't have a chance to look a...

On 11/7/19 3:36 PM, Jason Gunthorpe wrote: > On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote: > >>> So, I suppose it can be relaxed to a null test and a WARN_ON that it >>> hasn't changed? >> You mean >> >> if (use_ptemod) { >> ??????? WARN_ON(map->vma != vma); >> ??????? ... >> >> >> Yes, that sounds

On 11/4/19 9:31 PM, Jason Gunthorpe wrote: > On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote: >> On 10/28/19 4:10 PM, Jason Gunthorpe wrote: >>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma) >>> struct gntdev_priv *priv = file->private_data; >>> >>> pr_debug("gntdev_vma_close %p\n",

On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote: > > So, I suppose it can be relaxed to a null test and a WARN_ON that it > > hasn't changed? > > You mean > > if (use_ptemod) { > ??????? WARN_ON(map->vma != vma); > ??????? ... > > > Yes, that sounds good. I amended my copy of the patch with the above, has this rework shown signs

On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote: > On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > > @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma) > > struct gntdev_priv *priv = file->private_data; > > > > pr_debug("gntdev_vma_close %p\n", vma); > > - if (use_ptemod) { > > - /* It is possible

From: Jason Gunthorpe <jgg at mellanox.com> The new API is an exact match for the needs of radeon. For some reason radeon tries to remove overlapping ranges from the interval tree, but interval trees (and mmu_range_notifier_insert) support overlapping ranges directly. Simply delete all this code. Since this driver is missing a invalidate_range_end callback, but still calls get_user_pages(), it cannot be correct against all races. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: Christian K?nig <christian.koenig...

On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma) > struct gntdev_priv *priv = file->private_data; > > pr_debug("gntdev_vma_close %p\n", vma); > - if (use_ptemod) { > - /* It is possible that an mmu notifier could be running > - * concurrently, so take priv->lock to ensure that

Am 28.10.19 um 21:10 schrieb Jason Gunthorpe: > From: Jason Gunthorpe <jgg at mellanox.com> > > The new API is an exact match for the needs of radeon. > > For some reason radeon tries to remove overlapping ranges from the > interval tree, but interval trees (and mmu_range_notifier_insert) > support overlapping ranges directly. Simply delete all this code. > > Since this driver is missing a invalidate_range_end callback, but > still calls get_user_pages(), it cannot be correct against all races. > > Cc: Alex Deucher <alexander.deucher at amd.com> > Cc: Chr...

On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > gntdev simply wants to monitor a specific VMA for any notifier events, > this can be done straightforwardly using mmu_range_notifier_insert() over > the VMA's VA range. > > The notifier should be attached until the original VMA is destroyed. > > It is unclear if any of this is even sane, but at least a lot of duplicate > code is removed. I didn't have a chance to look at the patch itself yet but as a heads-up...

From: Jason Gunthorpe <jgg at mellanox.com> gntdev simply wants to monitor a specific VMA for any notifier events, this can be done straightforwardly using mmu_range_notifier_insert() over the VMA's VA range. The notifier should be attached until the original VMA is destroyed. It is unclear if any of this is even sane, but at least a lot of duplicate code is removed. Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko at epam.com> Cc: Boris Ostrovsky <boris.os...

...essor parts even if > disabled > mm/mmu_notifier: add an interval tree notifier > mm/hmm: allow hmm_range to be used with a mmu_range_notifier or > hmm_mirror > mm/hmm: define the pre-processor related parts of hmm.h even if > disabled > RDMA/odp: Use mmu_range_notifier_insert() > RDMA/hfi1: Use mmu_range_notifier_inset for user_exp_rcv > drm/radeon: use mmu_range_notifier_insert > xen/gntdev: Use select for DMA_SHARED_BUFFER > xen/gntdev: use mmu_range_notifier_insert > nouveau: use mmu_notifier directly for invalidate_range_start > n...

...ef CONFIG_LOCKDEP @@ -263,6 +289,78 @@ extern int __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm); extern void mmu_notifier_unregister(struct mmu_notifier *mn, struct mm_struct *mm); + +unsigned long mmu_range_read_begin(struct mmu_range_notifier *mrn); +int mmu_range_notifier_insert(struct mmu_range_notifier *mrn, + unsigned long start, unsigned long length, + struct mm_struct *mm); +int mmu_range_notifier_insert_locked(struct mmu_range_notifier *mrn, + unsigned long start, unsigned long length, + struct mm_struct *mm); +void mmu_range_notifier_...

...ht choice? > > Yes, it's my favorite too. I'd vote for going with that. Okay, lets give it a go > Very nice, would you be open to putting that into (any) one of the comment > headers? That's an unusually clear and concise description: Yep, done > > > > +int mmu_range_notifier_insert(struct mmu_range_notifier *mrn, > > > > + unsigned long start, unsigned long length, > > > > + struct mm_struct *mm) > > > > +{ > > > > + struct mmu_notifier_mm *mmn_mm; > > > > + int ret; > > > > > > Hmm...

...m/mmu_notifier: define the header pre-processor parts even if disabled mm/mmu_notifier: add an interval tree notifier mm/hmm: allow hmm_range to be used with a mmu_range_notifier or hmm_mirror mm/hmm: define the pre-processor related parts of hmm.h even if disabled RDMA/odp: Use mmu_range_notifier_insert() RDMA/hfi1: Use mmu_range_notifier_inset for user_exp_rcv drm/radeon: use mmu_range_notifier_insert xen/gntdev: Use select for DMA_SHARED_BUFFER xen/gntdev: use mmu_range_notifier_insert nouveau: use mmu_notifier directly for invalidate_range_start nouveau: use mmu_range_notifier inste...

..._ be an odd number and this close the loop with the above comments :) > > > + interval_tree_insert(&mrn->interval_tree, &mmn_mm->itree); > > + } > > + spin_unlock(&mmn_mm->lock); > > + return 0; > > +} > > + > > +/** > > + * mmu_range_notifier_insert - Insert a range notifier > > + * @mrn: Range notifier to register > > + * @start: Starting virtual address to monitor > > + * @length: Length of the range to monitor > > + * @mm : mm_struct to attach to > > + * > > + * This function subscribes the range notifier...

...89,78 @@ extern int __mmu_notifier_register(struct mmu_notifier *mn, > struct mm_struct *mm); > extern void mmu_notifier_unregister(struct mmu_notifier *mn, > struct mm_struct *mm); > + > +unsigned long mmu_range_read_begin(struct mmu_range_notifier *mrn); > +int mmu_range_notifier_insert(struct mmu_range_notifier *mrn, > + unsigned long start, unsigned long length, > + struct mm_struct *mm); > +int mmu_range_notifier_insert_locked(struct mmu_range_notifier *mrn, > + unsigned long start, unsigned long length, > + struct mm_struct *mm);...

...Splitting it makes alot of stuff more complex and unnatural. The ops above could be put in inline wrappers, but they only occur only in functions already called mn_itree_inv_start_range() and mn_itree_inv_end() and mn_itree_is_invalidating(). There is the one 'take the lock' outlier in __mmu_range_notifier_insert() though > > +static void mn_itree_inv_end(struct mmu_notifier_mm *mmn_mm) > > +{ > > + struct mmu_range_notifier *mrn; > > + struct hlist_node *next; > > + bool need_wake = false; > > + > > + spin_lock(&mmn_mm->lock); > > + if (--mmn_mm->a...

...&args, sizeof(args.i) + - pi * sizeof(args.phys[0]), - NULL); - svmm->vmm->vmm.object.client->super = false; - mutex_unlock(&svmm->mutex); - up_read(&mm->mmap_sem); + notifier.svmm = svmm; + notifier.notifier.ops = &nouveau_svm_mrn_ops; + ret = mmu_range_notifier_insert(&notifier.notifier, + args.i.p.addr, args.i.p.size, + svmm->notifier.mm); + if (!ret) { + ret = nouveau_range_fault( + svmm, svm->drm, &args, + sizeof(args.i) + pi * sizeof(args.phys[0]), + args.phys, &notifier); + mmu_range_notifier_remove(&notifier.no...

...t) { - hfi1_cdbg(TID, "Failed to insert RB node %u 0x%lx, 0x%lx %d", - node->rcventry, node->mmu.addr, node->phys, ret); - pci_unmap_single(dd->pcidev, phys, npages * PAGE_SIZE, - PCI_DMA_FROMDEVICE); - kfree(node); - return -EFAULT; + if (fd->use_mn) { + ret = mmu_range_notifier_insert( + &node->notifier, tbuf->vaddr + (pageidx * PAGE_SIZE), + npages * PAGE_SIZE, fd->mm); + if (ret) + goto out_unmap; + /* + * FIXME: This is in the wrong order, the notifier should be + * established before the pages are pinned by pin_rcv_pages. + */ + mmu_range_read_beg...