Quoting Rob Clark (2017-06-14 17:49:02)
> On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra
> 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 lockin
Hi Rob,
Yes, I’d completely missed the shrinker path in this cleanup. But, yeah, I see
how get_pages (which is called with msm_obj->lock held) -> drm_gem_get_pages
could trigger shrinker_scan which calls msm_gem_purge.
It makes sense to prevent any get_pages/vmap on objects that’ve been marked a
I think the trick is what is the best way to synchronize access to
msm_obj->madv in the shrinker path, since we can't reliably just take
msm_obj->lock in shrinker path since we might already hold it:
https://hastebin.com/ubafepahov.xml
fwiw, that was with my work-in-progress attempt to deal with s
On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra
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 recursi
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
On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra
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 recursi
