On Mon, 2024-04-29 at 01:11 +0000, Matthew Brost wrote:
> On Fri, Apr 26, 2024 at 04:32:36PM -0700, Matthew Brost wrote:
> > To be secure, when a userptr is invalidated the pages should be dma
> > unmapped ensuring the device can no longer touch the invalidated
> > pages.
> >
> > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel
> > GPUs")
> > Fixes: 12f4b58a37f4 ("drm/xe: Use hmm_range_fault to populate user
> > pages")
> > Cc: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx # 6.8
> > Signed-off-by: Matthew Brost <matthew.brost@xxxxxxxxx>
> > ---
> > drivers/gpu/drm/xe/xe_vm.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_vm.c
> > b/drivers/gpu/drm/xe/xe_vm.c
> > index dfd31b346021..964a5b4d47d8 100644
> > --- a/drivers/gpu/drm/xe/xe_vm.c
> > +++ b/drivers/gpu/drm/xe/xe_vm.c
> > @@ -637,6 +637,9 @@ static bool vma_userptr_invalidate(struct
> > mmu_interval_notifier *mni,
> > XE_WARN_ON(err);
> > }
> >
> > + if (userptr->sg)
> > + xe_hmm_userptr_free_sg(uvma);
> > +
>
> I thought about this a bit, I think here we only dma unmap the SG,
> not
> free it. Freeing it could cause a current bind walk to access corrupt
> memory. Freeing can be deferred to the next attempt to bind the
> userptr
> or userptr destroy.
Yes, makes sense.
/Thomas
>
> Matt
>
> > trace_xe_vma_userptr_invalidate_complete(vma);
> >
> > return true;
> > --
> > 2.34.1
> >
