search for: mmu_range_notifier

...9 at 04:04:08PM -0500, Jerome Glisse wrote: > On Thu, Nov 07, 2019 at 08:11:06PM +0000, Jason Gunthorpe wrote: > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > > > > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > > > header file, but I know that's extra work. Maybe later as a follow-up patch, > > > > if anyone has the time. > > > > > > The range notifier should get the event too, it would be a waste, i think it is > > > an oversight here. The rel...

...ier.h > @@ -6,10 +6,12 @@ > #include <linux/spinlock.h> > #include <linux/mm_types.h> > #include <linux/srcu.h> > +#include <linux/interval_tree.h> > > struct mmu_notifier_mm; > struct mmu_notifier; > struct mmu_notifier_range; > +struct mmu_range_notifier; Hi Jason, Nice design, I love the seq foundation! So far, I'm not able to spot anything actually wrong with the implementation, sorry about that. Generally my reaction is: given that the design is complex, try to mitigate that with documentation and naming. So the comments are in these ar...

...linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -6,10 +6,12 @@ #include <linux/spinlock.h> #include <linux/mm_types.h> #include <linux/srcu.h> +#include <linux/interval_tree.h> struct mmu_notifier_mm; struct mmu_notifier; struct mmu_notifier_range; +struct mmu_range_notifier; /** * enum mmu_notifier_event - reason for the mmu notifier callback @@ -32,6 +34,9 @@ struct mmu_notifier_range; * access flags). User should soft dirty the page in the end callback to make * sure that anyone relying on soft dirtyness catch pages that might be written * through non CPU...

...mu_notifier_range; > > * access flags). User should soft dirty the page in the end callback to make > > * sure that anyone relying on soft dirtyness catch pages that might be written > > * through non CPU mappings. > > + * > > + * @MMU_NOTIFY_RELEASE: used during mmu_range_notifier invalidate to signal that > > + * the mm refcount is zero and the range is no longer accessible. > > */ > > enum mmu_notifier_event { > > MMU_NOTIFY_UNMAP = 0, > > @@ -39,6 +44,7 @@ enum mmu_notifier_event { > > MMU_NOTIFY_PROTECTION_VMA, > > MMU_N...

...uash this into patch 14. With this is done, patch 12, 13, 14 is Reviewed-by and Tested-by Philip Yang <philip.yang at amd.com> Regards, Philip > Regards, > Jason > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-drm-amdgpu-issues-with-new-mmu_range_notifier-api.patch Type: text/x-patch Size: 5274 bytes Desc: 0001-drm-amdgpu-issues-with-new-mmu_range_notifier-api.patch URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20191101/40547648/attachment-0001.bin>

...it is always manipulated under a spinlock > 1. There is a rather severe naming overlap (not technically a naming conflict, > but still) with existing mmn work, which already has, for example: > > struct mmu_notifier_range > > ...and you're adding: > > struct mmu_range_notifier > > ...so I'll try to help sort that out. Yes, I've been sad about this too. > So this should read: > > enum mmu_range_notifier_event { > MMU_NOTIFY_RELEASE, > }; > > ...assuming that we stay with "mmu_range_notifier" as a core name for this >...

From: Jason Gunthorpe <jgg at mellanox.com> Remove the hmm_mirror object and use the mmu_range_notifier API instead for the range, and use the normal mmu_notifier API for the general invalidation callback. While here re-organize the pagefault path so the locking pattern is clear. nouveau is the only driver that uses a temporary range object and instead forwards nearly every invalidation range direc...

...gt; > On Thu, Nov 07, 2019 at 08:11:06PM +0000, Jason Gunthorpe wrote: > > > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > > > > > > > > > > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > > > > > header file, but I know that's extra work. Maybe later as a follow-up patch, > > > > > > if anyone has the time. > > > > > > > > > > The range notifier should get the event too, it would be a waste, i think it is &...

On Fri, Nov 01, 2019 at 03:59:26PM +0000, Yang, Philip wrote: > > This test for range_blockable should be before mutex_lock, I can move > > it up > > > yes, thanks. Okay, I wrote it like this: if (mmu_notifier_range_blockable(range)) mutex_lock(&adev->notifier_lock); else if (!mutex_trylock(&adev->notifier_lock)) return false; > > Also, do you

On Fri, Nov 01, 2019 at 02:44:51PM +0000, Yang, Philip wrote: > @@ -854,12 +853,20 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, struct page **pages) > r = -EPERM; > goto out_unlock; > } > + up_read(&mm->mmap_sem); > + timeout = jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT); > + > +retry: > + range->notifier_seq =

...rome Glisse wrote: > > On Thu, Nov 07, 2019 at 08:11:06PM +0000, Jason Gunthorpe wrote: > > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > > > > > > > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > > > > header file, but I know that's extra work. Maybe later as a follow-up patch, > > > > > if anyone has the time. > > > > > > > > The range notifier should get the event too, it would be a waste, i think it is > > > > a...

On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > header file, but I know that's extra work. Maybe later as a follow-up patch, > > if anyone has the time. > > The range notifier should get the event too, it would be a waste, i think it is > an oversight here. The release event is fine so NAK to you separate event. E...

On Thu, Nov 07, 2019 at 08:06:08PM +0000, Jason Gunthorpe wrote: > > > > enum mmu_range_notifier_event { > > MMU_NOTIFY_RELEASE, > > }; > > > > ...assuming that we stay with "mmu_range_notifier" as a core name for this > > whole thing. > > > > Also, it is best moved down to be next to the new MNR structs, so that all the > > MNR stu...

...f the 'struct > mmu_notifier_range' (ie the description of the invalidation) and it > doesn't really matter that only these new notifiers can be called with > this type, it is still part of the mmu_notifier_range. > OK. > The comment already says it only applies to the mmu_range_notifier > scheme.. > >>> #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0) >>> @@ -222,6 +228,26 @@ struct mmu_notifier { >>> unsigned int users; >>> }; >>> >> >> That should also be moved down, next to the new structs. > >...

...e some remarks: > >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c >> index cb718a064eb4..c8bbd06f1009 100644 >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c >> @@ -67,21 +67,15 @@ static bool amdgpu_mn_invalidate_gfx(struct mmu_range_notifier *mrn, >> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); >> long r; >> >> - /* >> - * FIXME: Must hold some lock shared with >> - * amdgpu_ttm_tt_get_user_pages_done() >> - */ >> - mmu_range_set_seq(mrn, cur_seq); >> +...

...lanox.com> > > Convert the collision-retry lock around hmm_range_fault to use the one now > provided by the mmu_range notifier. > > Although this driver does not seem to use the collision retry lock that > hmm provides correctly, it can still be converted over to use the > mmu_range_notifier api instead of hmm_mirror without too much trouble. > > This also deletes another place where a driver is associating additional > data (struct amdgpu_mn) with a mmu_struct. > > Cc: Alex Deucher <alexander.deucher at amd.com> > Cc: Christian K?nig <christian.koenig at a...

...rom: Jason Gunthorpe <jgg at mellanox.com> Convert the collision-retry lock around hmm_range_fault to use the one now provided by the mmu_range notifier. Although this driver does not seem to use the collision retry lock that hmm provides correctly, it can still be converted over to use the mmu_range_notifier api instead of hmm_mirror without too much trouble. This also deletes another place where a driver is associating additional data (struct amdgpu_mn) with a mmu_struct. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: Christian K?nig <christian.koenig at amd.com> Cc: David (ChunMing...

...igned off by Here are some remarks: > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c > index cb718a064eb4..c8bbd06f1009 100644 > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c > @@ -67,21 +67,15 @@ static bool amdgpu_mn_invalidate_gfx(struct mmu_range_notifier *mrn, > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); > long r; > > - /* > - * FIXME: Must hold some lock shared with > - * amdgpu_ttm_tt_get_user_pages_done() > - */ > - mmu_range_set_seq(mrn, cur_seq); > + mutex_lock(&adev->notifier_lock...

On Tue, Oct 29, 2019 at 07:22:37PM +0000, Yang, Philip wrote: > Hi Jason, > > I did quick test after merging amd-staging-drm-next with the > mmu_notifier branch, which includes this set changes. The test result > has different failures, app stuck intermittently, GUI no display etc. I > am understanding the changes and will try to figure out the cause. Thanks! I'm not

...cking/READ_ONCe - Make the WARN_ON flow in mn_itree_invalidate a bit easier to follow - Fix wrong WARN_ON Jason Gunthorpe (15): mm/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/gn...