All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sean Paul <sean@poorly.run>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	freedreno <freedreno@lists.freedesktop.org>
Subject: Re: [PATCH] drm/msm: Don't call dma_buf_vunmap without _vmap
Date: Sun, 31 May 2020 09:02:11 -0700	[thread overview]
Message-ID: <CAF6AEGskgFyDxX+MWF84Z53ATmVd3972py88Og=aLQFV0d7UPQ@mail.gmail.com> (raw)
In-Reply-To: <20200514201117.465146-1-daniel.vetter@ffwll.ch>

On Thu, May 14, 2020 at 1:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> I honestly don't exactly understand what's going on here, but the
> current code is wrong for sure: It calls dma_buf_vunmap without ever
> calling dma_buf_vmap.
>
> What I'm not sure about is whether the WARN_ON is correct:
> - msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
>   a pretty neat layering violation of how you shouldn't peek behind
>   the curtain of the dma-buf exporter, but par for course. Note that
>   all the nice new helpers don't (and we should probably have a bit a
>   warning about this in the kerneldoc).
>
> - but then in the get_vaddr() in msm_gem.c, we seems to happily wrap a
>   vmap() around any object with ->pages set (so including imported
>   dma-buf).
>
> - I'm not seeing any guarantees that userspace can't use an imported
>   dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no
>   guarantees that an imported dma-buf won't end up with a ->vaddr set.
>
> But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
> calling dma_buf_vunmap is the wrong thing to do.
>
> v2: Rob said in review that we do indeed have a gap in get_vaddr() that
> needs to be plugged. But the users I've found aren't legit users on
> imported dma-buf, so we can just reject that.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org

Reviewed-by: Rob Clark <robdclark@gmail.com>

> ---
>  drivers/gpu/drm/msm/msm_gem.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 5a6a79fbc9d6..e70abd1cde43 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -554,6 +554,9 @@ static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
>         struct msm_gem_object *msm_obj = to_msm_bo(obj);
>         int ret = 0;
>
> +       if (obj->import_attach)
> +               return ERR_PTR(-ENODEV);
> +
>         mutex_lock(&msm_obj->lock);
>
>         if (WARN_ON(msm_obj->madv > madv)) {
> @@ -907,8 +910,7 @@ static void free_object(struct msm_gem_object *msm_obj)
>         put_iova(obj);
>
>         if (obj->import_attach) {
> -               if (msm_obj->vaddr)
> -                       dma_buf_vunmap(obj->import_attach->dmabuf, msm_obj->vaddr);
> +               WARN_ON(msm_obj->vaddr);
>
>                 /* Don't drop the pages for imported dmabuf, as they are not
>                  * ours, just free the array we allocated:
> --
> 2.26.2
>

WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	freedreno <freedreno@lists.freedesktop.org>,
	Sean Paul <sean@poorly.run>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH] drm/msm: Don't call dma_buf_vunmap without _vmap
Date: Sun, 31 May 2020 09:02:11 -0700	[thread overview]
Message-ID: <CAF6AEGskgFyDxX+MWF84Z53ATmVd3972py88Og=aLQFV0d7UPQ@mail.gmail.com> (raw)
In-Reply-To: <20200514201117.465146-1-daniel.vetter@ffwll.ch>

On Thu, May 14, 2020 at 1:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> I honestly don't exactly understand what's going on here, but the
> current code is wrong for sure: It calls dma_buf_vunmap without ever
> calling dma_buf_vmap.
>
> What I'm not sure about is whether the WARN_ON is correct:
> - msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
>   a pretty neat layering violation of how you shouldn't peek behind
>   the curtain of the dma-buf exporter, but par for course. Note that
>   all the nice new helpers don't (and we should probably have a bit a
>   warning about this in the kerneldoc).
>
> - but then in the get_vaddr() in msm_gem.c, we seems to happily wrap a
>   vmap() around any object with ->pages set (so including imported
>   dma-buf).
>
> - I'm not seeing any guarantees that userspace can't use an imported
>   dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no
>   guarantees that an imported dma-buf won't end up with a ->vaddr set.
>
> But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
> calling dma_buf_vunmap is the wrong thing to do.
>
> v2: Rob said in review that we do indeed have a gap in get_vaddr() that
> needs to be plugged. But the users I've found aren't legit users on
> imported dma-buf, so we can just reject that.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org

Reviewed-by: Rob Clark <robdclark@gmail.com>

> ---
>  drivers/gpu/drm/msm/msm_gem.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 5a6a79fbc9d6..e70abd1cde43 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -554,6 +554,9 @@ static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
>         struct msm_gem_object *msm_obj = to_msm_bo(obj);
>         int ret = 0;
>
> +       if (obj->import_attach)
> +               return ERR_PTR(-ENODEV);
> +
>         mutex_lock(&msm_obj->lock);
>
>         if (WARN_ON(msm_obj->madv > madv)) {
> @@ -907,8 +910,7 @@ static void free_object(struct msm_gem_object *msm_obj)
>         put_iova(obj);
>
>         if (obj->import_attach) {
> -               if (msm_obj->vaddr)
> -                       dma_buf_vunmap(obj->import_attach->dmabuf, msm_obj->vaddr);
> +               WARN_ON(msm_obj->vaddr);
>
>                 /* Don't drop the pages for imported dmabuf, as they are not
>                  * ours, just free the array we allocated:
> --
> 2.26.2
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-05-31 16:01 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11  9:35 [PATCH 0/9] shmem helper untangling Daniel Vetter
2020-05-11  9:35 ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 1/9] drm/msm: Don't call dma_buf_vunmap without _vmap Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35   ` Daniel Vetter
2020-05-11 15:24   ` Rob Clark
2020-05-11 15:24     ` [Intel-gfx] " Rob Clark
2020-05-11 15:24     ` Rob Clark
2020-05-11 15:28     ` Daniel Vetter
2020-05-11 15:28       ` [Intel-gfx] " Daniel Vetter
2020-05-11 15:28       ` Daniel Vetter
2020-05-11 20:36       ` Rob Clark
2020-05-11 20:36         ` [Intel-gfx] " Rob Clark
2020-05-11 20:36         ` Rob Clark
2020-05-14 20:11   ` [PATCH] " Daniel Vetter
2020-05-14 20:11     ` Daniel Vetter
2020-05-28  8:29     ` Daniel Vetter
2020-05-28  8:29       ` Daniel Vetter
2020-05-31 16:02     ` Rob Clark [this message]
2020-05-31 16:02       ` Rob Clark
2020-06-03 12:46       ` Daniel Vetter
2020-06-03 12:46         ` Daniel Vetter
2020-05-11  9:35 ` [PATCH 2/9] drm/gem: WARN if drm_gem_get_pages is called on a private obj Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:45   ` Thomas Zimmermann
2020-05-14  7:45     ` [Intel-gfx] " Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 3/9] drm/doc: Some polish for shmem helpers Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11 11:12   ` Thomas Zimmermann
2020-05-11 11:12     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 20:05     ` Daniel Vetter
2020-05-14 20:05       ` [Intel-gfx] " Daniel Vetter
2020-05-15  6:26       ` Thomas Zimmermann
2020-05-15  6:26         ` [Intel-gfx] " Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 4/9] drm/virtio: Call the right " Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35   ` Daniel Vetter
2020-05-14  7:46   ` Thomas Zimmermann
2020-05-14  7:46     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14  7:46     ` Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 5/9] drm/udl: Don't call get/put_pages on imported dma-buf Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11 11:23   ` Thomas Zimmermann
2020-05-11 11:23     ` [Intel-gfx] " Thomas Zimmermann
2020-05-11 11:37     ` Daniel Vetter
2020-05-11 11:37       ` [Intel-gfx] " Daniel Vetter
2020-05-11 12:04       ` Thomas Zimmermann
2020-05-11 12:04         ` [Intel-gfx] " Thomas Zimmermann
2020-05-14  7:25   ` Thomas Zimmermann
2020-05-14  7:25     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:47     ` Daniel Vetter
2020-05-14 12:47       ` [Intel-gfx] " Daniel Vetter
2020-06-03 12:57       ` Daniel Vetter
2020-06-03 12:57         ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 6/9] drm/shmem-helpers: Don't call get/put_pages on imported dma-buf in vmap Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:16   ` Thomas Zimmermann
2020-05-14  7:16     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:49     ` Daniel Vetter
2020-05-14 12:49       ` [Intel-gfx] " Daniel Vetter
2020-05-14 20:22     ` [PATCH] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:23   ` Thomas Zimmermann
2020-05-14  7:23     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:47     ` Daniel Vetter
2020-05-14 12:47       ` [Intel-gfx] " Daniel Vetter
2020-05-27 18:32   ` Thomas Zimmermann
2020-05-27 18:32     ` [Intel-gfx] " Thomas Zimmermann
2020-05-27 19:34     ` Daniel Vetter
2020-05-27 19:34       ` [Intel-gfx] " Daniel Vetter
2020-05-28 12:53       ` Thomas Zimmermann
2020-05-28 12:53         ` [Intel-gfx] " Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 8/9] drm/shmem-helpers: Ensure get_pages is not called on " Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:30   ` Thomas Zimmermann
2020-05-14  7:30     ` [Intel-gfx] " Thomas Zimmermann
2020-06-03 13:12     ` Daniel Vetter
2020-06-03 13:12       ` [Intel-gfx] " Daniel Vetter
2020-06-08 14:40       ` Thomas Zimmermann
2020-06-08 14:40         ` [Intel-gfx] " Thomas Zimmermann
2020-06-08 15:04         ` Daniel Vetter
2020-06-08 15:04           ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 9/9] drm/shmem-helpers: Simplify dma-buf importing Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:44   ` Thomas Zimmermann
2020-05-14  7:44     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:55     ` Daniel Vetter
2020-05-14 12:55       ` [Intel-gfx] " Daniel Vetter
2020-05-14 15:26       ` Thomas Zimmermann
2020-05-14 15:26         ` [Intel-gfx] " Thomas Zimmermann
2020-05-20 18:02   ` [PATCH] " Daniel Vetter
2020-05-29 13:34     ` Boris Brezillon
2020-05-29 13:35       ` Boris Brezillon
2020-05-29 13:49     ` Boris Brezillon
2020-05-29 14:05     ` Daniel Vetter
2020-05-29 14:36       ` Boris Brezillon
2020-06-15  8:23   ` [PATCH 9/9] " Thomas Zimmermann
2020-06-15  8:23     ` [Intel-gfx] " Thomas Zimmermann
2020-05-11 11:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for shmem helper untangling Patchwork
2020-05-11 11:56 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-05-11 14:30 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-05-29 13:52 ` [PATCH 0/9] " Boris Brezillon
2020-05-29 13:52   ` [Intel-gfx] " Boris Brezillon

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='CAF6AEGskgFyDxX+MWF84Z53ATmVd3972py88Og=aLQFV0d7UPQ@mail.gmail.com' \
    --to=robdclark@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=sean@poorly.run \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.