From: ssusheel-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
To: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Chris Wilson
<chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Subject: Re: [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex
Date: Fri, 16 Jun 2017 15:32:10 -0600 [thread overview]
Message-ID: <6c29e4e08cab26ecfedcde1e6c2472d3@codeaurora.org> (raw)
In-Reply-To: <20170616142207.20821-1-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Rob,
This looks good to me!
Just one nit: msm_gem_vunmap becomes very shrinker specific as it holds
the msm_obj->lock with the shrinker class. Should we have the caller
i.e. msm_gem_shrinker_vmap hold it instead? Or change it's name to
msm_gem_vunmap_shrinker or something like that...?
It does make sense to make the madv/priv->inactive_list locking cleanup
separately.
Thanks,
Sushmita
On 2017-06-16 08:22, Rob Clark wrote:
> ---
> Ok, 2nd fixup to handle vmap shrinking.
>
> drivers/gpu/drm/msm/msm_gem.c | 44
> +++++++++++++++++++++++++++++++++++--------
> 1 file changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c
> b/drivers/gpu/drm/msm/msm_gem.c
> index f5d1f84..3190e05 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -42,6 +42,9 @@ enum {
> OBJ_LOCK_SHRINKER,
> };
>
> +static void msm_gem_vunmap_locked(struct drm_gem_object *obj);
> +
> +
> static dma_addr_t physaddr(struct drm_gem_object *obj)
> {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> @@ -484,6 +487,7 @@ int msm_gem_dumb_map_offset(struct drm_file *file,
> struct drm_device *dev,
> void *msm_gem_get_vaddr(struct drm_gem_object *obj)
> {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> + int ret = 0;
>
> mutex_lock(&msm_obj->lock);
>
> @@ -492,22 +496,35 @@ void *msm_gem_get_vaddr(struct drm_gem_object
> *obj)
> return ERR_PTR(-EBUSY);
> }
>
> + /* increment vmap_count *before* vmap() call, so shrinker can
> + * check vmap_count (is_vunmapable()) outside of msm_obj->lock.
> + * This guarantees that we won't try to msm_gem_vunmap() this
> + * same object from within the vmap() call (while we already
> + * hold msm_obj->lock)
> + */
> + msm_obj->vmap_count++;
> +
> if (!msm_obj->vaddr) {
> struct page **pages = get_pages(obj);
> if (IS_ERR(pages)) {
> - mutex_unlock(&msm_obj->lock);
> - return ERR_CAST(pages);
> + ret = PTR_ERR(pages);
> + goto fail;
> }
> msm_obj->vaddr = vmap(pages, obj->size >> PAGE_SHIFT,
> VM_MAP, pgprot_writecombine(PAGE_KERNEL));
> if (msm_obj->vaddr == NULL) {
> - mutex_unlock(&msm_obj->lock);
> - return ERR_PTR(-ENOMEM);
> + ret = -ENOMEM;
> + goto fail;
> }
> }
> - msm_obj->vmap_count++;
> +
> mutex_unlock(&msm_obj->lock);
> return msm_obj->vaddr;
> +
> +fail:
> + msm_obj->vmap_count--;
> + mutex_unlock(&msm_obj->lock);
> + return ERR_PTR(ret);
> }
>
> void msm_gem_put_vaddr(struct drm_gem_object *obj)
> @@ -554,7 +571,7 @@ void msm_gem_purge(struct drm_gem_object *obj)
>
> put_iova(obj);
>
> - msm_gem_vunmap(obj);
> + msm_gem_vunmap_locked(obj);
>
> put_pages(obj);
>
> @@ -576,10 +593,12 @@ void msm_gem_purge(struct drm_gem_object *obj)
> mutex_unlock(&msm_obj->lock);
> }
>
> -void msm_gem_vunmap(struct drm_gem_object *obj)
> +static void msm_gem_vunmap_locked(struct drm_gem_object *obj)
> {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
>
> + WARN_ON(!mutex_is_locked(&msm_obj->lock));
> +
> if (!msm_obj->vaddr || WARN_ON(!is_vunmapable(msm_obj)))
> return;
>
> @@ -587,6 +606,15 @@ void msm_gem_vunmap(struct drm_gem_object *obj)
> msm_obj->vaddr = NULL;
> }
>
> +void msm_gem_vunmap(struct drm_gem_object *obj)
> +{
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> +
> + mutex_lock_nested(&msm_obj->lock, OBJ_LOCK_SHRINKER);
> + msm_gem_vunmap_locked(obj);
> + mutex_unlock(&msm_obj->lock);
> +}
> +
> /* must be called before _move_to_active().. */
> int msm_gem_sync_object(struct drm_gem_object *obj,
> struct msm_fence_context *fctx, bool exclusive)
> @@ -799,7 +827,7 @@ void msm_gem_free_object(struct drm_gem_object
> *obj)
>
> drm_prime_gem_destroy(obj, msm_obj->sgt);
> } else {
> - msm_gem_vunmap(obj);
> + msm_gem_vunmap_locked(obj);
> put_pages(obj);
> }
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
next prev parent reply other threads:[~2017-06-16 21:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-13 22:52 [PATCH] drm/msm: Separate locking of buffer resources from struct_mutex Sushmita Susheelendra
[not found] ` <1497394374-19982-1-git-send-email-ssusheel-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-06-13 23:10 ` Rob Clark
2017-06-14 16:49 ` Rob Clark
[not found] ` <CAF6AEGuUNmpbssk0nsf6Nrb3Z-H5ug-gthEkZTqg_9GQAA3iUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-14 23:08 ` Susheelendra, Sushmita
2017-06-14 23:31 ` Rob Clark
2017-06-15 10:19 ` Chris Wilson
2017-06-15 13:20 ` [PATCH] fixup! " Rob Clark
[not found] ` <20170615132050.1196-1-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-06-15 21:59 ` Susheelendra, Sushmita
[not found] ` <D38DFC6B-2CE4-459F-9D35-C21CEE5B362D-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-06-15 22:57 ` Rob Clark
[not found] ` <CAF6AEGst=tPn30N-0u5J8-FkBb=ZKKNkjEBGE-M84TxnC054Vw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-16 14:22 ` Rob Clark
[not found] ` <20170616142207.20821-1-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-06-16 21:32 ` ssusheel-sgV2jX0FEOL9JmXXK+q4OQ [this message]
2017-06-16 21:44 ` [Freedreno] " Rob Clark
[not found] ` <CAF6AEGvbf_bwDz9CHPd-BhNHFaBngspfyV1OE=m8YAtm+W1T2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-16 23:04 ` Sushmita Susheelendra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6c29e4e08cab26ecfedcde1e6c2472d3@codeaurora.org \
--to=ssusheel-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).