Quoting Rob Clark (2017-06-14 17:49:02) > On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra > <ssusheel@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html