[RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes

[Hellstrom, Thomas]

On Fri, 2022-07-08 at 07:51 -0700, Niranjana Vishwanathapura wrote:
> > Since we don't loop over the vm_bound_list, there is a need to
> > check
> > whether the rebind_list is empty here under the notifier_lock in
> > read
> > mode, and in that case, restart from eb_lookup_vmas(). That might
> > also
> > eliminate the need for the __EXEC3_USERPTR_USED flag?
> > 
> > That will also catch any objects that were evicted between
> > eb_lookup_vmas() where the rebind_list was last checked, and
> > i915_gem_vm_priv_lock(), which prohibits further eviction, but if
> > we
> > want to catch these earlier (which I think is a good idea), we
> > could
> > check that the rebind_list is indeed empty just after taking the
> > vm_priv_lock(), and if not, restart from eb_lookup_vmas().
> 
> Yah, right, we need to check rebind_list here and if not empty,
> restart
> from lookup phase.
> It is bit tricky with userptr here as the unbind happens during
> submit_init() call after we scoop unbound vmas here, the vmas gets
> re-added to rebind_list :(.

Ugh.

> I think we need a separate 'invalidated_userptr_list' here and we
> iterate through it for submit_init() and submit_done() calls (yes,
> __EXEC3_USERPTR_USED flag won't be needed then).
> And, we call, eb_scoop_unbound_vmas() after calling
> eb_lookup_persistent_userptr_vmas(), so that we scoop all unbound
> vmas properly.
> 

I'm not sure that will help much, because we'd also need to recheck the
rebind_list and possibly restart after taking the vm_priv_lock, since
objects can be evicted between the scooping and taking the
vm_priv_lock. So then the userptrs will be caught by that check.

/Thomas