[PATCH] drm/msm: Separate locking of buffer resources from struct_mutex

[Chris Wilson]

Quoting Rob Clark (2017-06-14 17:49:02)
> On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra
> <ssusheel at codeaurora.org> wrote:
> > Buffer object specific resources like pages, domains, sg list
> > need not be protected with struct_mutex. They can be protected
> > with a buffer object level lock. This simplifies locking and
> > makes it easier to avoid potential recursive locking scenarios
> > for SVM involving mmap_sem and struct_mutex. This also removes
> > unnecessary serialization when creating buffer objects, and also
> > between buffer object creation and GPU command submission.
> 
> I've rebased this on top of the other changes that are in the queue for 4.13:
> 
> https://github.com/freedreno/kernel-msm/commit/4e0c4e139a647914cfcf7c413da5c19f9f124885
> 
> I've done some light testing on a5xx.. although between this and
> moving gpu->hw_init() under struct_mutex, I need to double check on
> a3xx/a4xx.
> 
> I do think we probably need a bit more work for shrinker.  In
> particular msm_gem_purge() still assumes everything is protected by a
> single struct_mutex, which is no longer true.  The tricky thing here
> is that shrinker can be triggered by code-paths where we already hold
> msm_obj->lock.

Make sure that msm_obj->lock *only* covers the backing store (and its
operations). (e.g. I called it obj->mm.lock and moved everything that it
covers into obj->mm). Then you can ensure that you don't attempt to
shrink msm_obj itself whilst holding msm_obj->mm.lock (e.g. by tracking
a obj->mm.pages_pin_count and not attempting to shrink any object that
has its pages still pinned, and you then only allocate underneath the
msm_obj->mm.lock whilst holding a page reference). After all that you
can use mutex_lock_nested(.subclass = MSM_SHRINKER) for the special case
where the shrinker may be acquiring the lock on other objects whilst
holding msm_obj->mm.lock.
-Chris