search for: mmgrab

...red_item, + &removed_list); + } } spin_unlock(&mmn_mm->lock); + hlist_for_each_entry_safe(mni, next, &removed_list, deferred_item) { + struct mm_struct *mm = mni->mm; + + hlist_del(&mni->deferred_item); + mni->ops->release(mni); + + /* pairs with mmgrab() in __mmu_interval_notifier_insert() */ + mmdrop(mm); + } + wake_up_all(&mmn_mm->wq); } @@ -1006,24 +1022,13 @@ int mmu_interval_notifier_insert_safe( } EXPORT_SYMBOL_GPL(mmu_interval_notifier_insert_safe); -/** - * mmu_interval_notifier_remove - Remove a interval notifier - * @mn...

..., it also creates the kthread in the vhost core (but we can add another variable to avoid this). My biggest concern is the comment in include/linux/sched/mm.h. get_task_mm() uses mmget(), but in the documentation they advise against pinning the address space indefinitely, so I preferred in keeping mmgrab() in the vhost core, then call mmget_not_zero() in the worker only when it is running. In the future maybe mm will be used differently from parent if somehow it is supported by iommu, so I would leave it to the parent to handle this. Thanks, Stefano

...& AMDGPU_GEM_USERPTR_ANONONLY) && > - vma->vm_file)) { > - r = -EPERM; > - goto out; > - } > + mm = mirror->hmm->mmu_notifier.mm; > + if (!mmget_not_zero(mm)) /* Happens during process shutdown */ This works because mirror->hmm->mmu_notifier holds an mmgrab reference to the mm? So the MM will not just go away, but if the mmget refcount is 0, it means the mm is marked for destruction and shouldn't be used any more. > + return -ESRCH; > > range = kzalloc(sizeof(*range), GFP_KERNEL); > if (unlikely(!range)) { > @@ -847,6...

...ore (but we can add another variable to avoid this). >> >> My biggest concern is the comment in include/linux/sched/mm.h. >> get_task_mm() uses mmget(), but in the documentation they advise against >> pinning the address space indefinitely, so I preferred in keeping >> mmgrab() in the vhost core, then call mmget_not_zero() in the worker >> only when it is running. > >Ok. > >> >> In the future maybe mm will be used differently from parent if somehow >> it is supported by iommu, so I would leave it to the parent to handle >> this. &g...

...+ mmu_notifier_mm->itree = RB_ROOT_CACHED; + init_waitqueue_head(&mmu_notifier_mm->wq); + INIT_HLIST_HEAD(&mmu_notifier_mm->deferred_list); } ret = mm_take_all_locks(mm); if (unlikely(ret)) goto out_clean; - /* Pairs with the mmdrop in mmu_notifier_unregister_* */ - mmgrab(mm); - /* * Serialize the update against mmu_notifier_unregister. A * side note: mmu_notifier_release can't run concurrently with @@ -306,13 +614,28 @@ int __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm) * current->mm or explicitly with get_task_mm() or simi...

...+ mmu_notifier_mm->itree = RB_ROOT_CACHED; + init_waitqueue_head(&mmu_notifier_mm->wq); + INIT_HLIST_HEAD(&mmu_notifier_mm->deferred_list); } ret = mm_take_all_locks(mm); if (unlikely(ret)) goto out_clean; - /* Pairs with the mmdrop in mmu_notifier_unregister_* */ - mmgrab(mm); - /* * Serialize the update against mmu_notifier_unregister. A * side note: mmu_notifier_release can't run concurrently with @@ -306,13 +617,28 @@ int __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm) * current->mm or explicitly with get_task_mm() or simi...

...; So why is this important enough for a TODO comment, but not important enough to do right away? > + * release semantics on the initialization of the mmu_notifier_mm's > + * contents are provided for unlocked readers. acquire can only be > + * used while holding the mmgrab or mmget, and is safe because once > + * created the mmu_notififer_mm is not freed until the mm is > + * destroyed. As above, users holding the mmap_sem or one of the > + * mm_take_all_locks() do not need to use acquire semantics. > */ Some spaces instead of...

...+ > + ret = mmu_interval_notifier_insert(&dmirror->notifier, current->mm, > + 0, ULONG_MAX & PAGE_MASK, &dmirror_min_ops); > + if (ret) { > + kfree(dmirror); > + return ret; > + } > + > + /* Pairs with the mmdrop() in dmirror_fops_release(). */ > + mmgrab(current->mm); > + dmirror->mm = current->mm; The notifier holds a mmgrab, no need for another one > + /* Only the first open registers the address space. */ > + filp->private_data = dmirror; Not sure what this comment means > +static inline struct dmirror_device *dmirror...

...similar). * We can't race against any other mmu notifier method either * thanks to mm_take_all_locks(). * * release semantics on the initialization of the mmu_notifier_mm's * contents are provided for unlocked readers. acquire can only be * used while holding the mmgrab or mmget, and is safe because once * created the mmu_notififer_mm is not freed until the mm is * destroyed. As above, users holding the mmap_sem or one of the * mm_take_all_locks() do not need to use acquire semantics. */ if (mmu_notifier_mm) smp_store_release(&...

On 3/17/20 5:59 AM, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: >> I've been using v7 of Ralph's tester and it is working well - it has >> DEVICE_PRIVATE support so I think it can test this flow too. Ralph are >> you able? >> >> This hunk seems trivial enough to me, can we include it now? > > I can send

...ifier_insert(&dmirror->notifier, current->mm, >> + 0, ULONG_MAX & PAGE_MASK, &dmirror_min_ops); >> + if (ret) { >> + kfree(dmirror); >> + return ret; >> + } >> + >> + /* Pairs with the mmdrop() in dmirror_fops_release(). */ >> + mmgrab(current->mm); >> + dmirror->mm = current->mm; > > The notifier holds a mmgrab, no need for another one OK. I'll replace dmirror->mm with dmirror->notifier.mm. >> + /* Only the first open registers the address space. */ >> + filp->private_data = dmirr...

...ent, I'm noto sure wake_up_q is even a function this layer should be calling. > > + * release semantics on the initialization of the mmu_notifier_mm's > > + * contents are provided for unlocked readers. acquire can only be > > + * used while holding the mmgrab or mmget, and is safe because once > > + * created the mmu_notififer_mm is not freed until the mm is > > + * destroyed. As above, users holding the mmap_sem or one of the > > + * mm_take_all_locks() do not need to use acquire semantics. > > */ &gt...

...ied + * mm context. + * (Note: this routine is intended to be called only + * from a kernel thread context) + */ +void use_mm(struct mm_struct *mm) +{ + struct mm_struct *active_mm; + struct task_struct *tsk = current; + + task_lock(tsk); + active_mm = tsk->active_mm; + if (active_mm != mm) { + mmgrab(mm); + tsk->active_mm = mm; + } + tsk->mm = mm; + switch_mm(active_mm, mm, tsk); + task_unlock(tsk); +#ifdef finish_arch_post_lock_switch + finish_arch_post_lock_switch(); +#endif + + if (active_mm != mm) + mmdrop(active_mm); +} +EXPORT_SYMBOL_GPL(use_mm); + +/* + * unuse_mm + * Reverses th...

...;t race against any other mmu notifier method either > * thanks to mm_take_all_locks(). > * > * release semantics on the initialization of the mmu_notifier_mm's > * contents are provided for unlocked readers. acquire can only be > * used while holding the mmgrab or mmget, and is safe because once > * created the mmu_notififer_mm is not freed until the mm is > * destroyed. As above, users holding the mmap_sem or one of the > * mm_take_all_locks() do not need to use acquire semantics. > */ > if (mmu_notifier_mm)...

...lete online memory block first virtio-mem: Don't rely on implicit compiler padding for requests Guennadi Liakhovetski (1): vhost: (cosmetic) remove a superfluous variable initialisation Jason Wang (4): vhost: allow device that does not depend on vhost worker vhost: use mmgrab() instead of mmget() for non worker device vdpa: introduce get_vq_notification method vhost_vdpa: support doorbell mapping via mmap Longpeng(Mike) (3): crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() crypto: virtio: Fix use-after-fre...

...tem for the test. If the feature isn't selected, > no need to test it :-) I ment if DEVICE_PRIVATE should be a user selectable option at all, or should it be turned on when a driver like nouveau is selected. Is there some downside to enabling DEVICE_PRIVATE? > > The notifier holds a mmgrab, no need for another one > > OK. I'll replace dmirror->mm with dmirror->notifier.mm. Right that is good too > > > + filp->private_data = dmirror; > > > > Not sure what this comment means > > I'll change the comment to: > /* >...

On Tue, Mar 21, 2023 at 11:48?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > The new "use_va" module parameter (default: true) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

...the one I used does not meet those requirements. So a new virtio-pci driver for vDPA bus is introduced, and I verify this with page-per-vq=on with a userspace vhost-vdpa driver in guest. Please review. Thanks Jason Wang (6): vhost: allow device that does not depend on vhost worker vhost: use mmgrab() instead of mmget() for non worker device vdpa: introduce get_vq_notification method vhost_vdpa: support doorbell mapping via mmap vdpa: introduce virtio pci driver vdpa: vp_vdpa: report doorbell location drivers/vdpa/Kconfig | 6 + drivers/vdpa/Makefile | 1 + dri...