From: Thomas Hellstrom <thellstrom@vmware.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: linux-graphics-maintainer@vmware.com,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 08/16] drm/vmwgfx: implement mmap access managament
Date: Wed, 14 Aug 2013 19:35:18 +0200 [thread overview]
Message-ID: <520BBFD6.8050205@vmware.com> (raw)
In-Reply-To: <CANq1E4TE--vu9fkHWuez+vma_HBguA6MTCE7-Kf=RvVpNy_byA@mail.gmail.com>
(CC'ing the proper people since I'm still on parental leave).
On 08/13/2013 11:44 PM, David Herrmann wrote:
Please see inline comments.
> Hi
>
> On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Correctly allow and revoke buffer access on each open/close via the new
>> VMA offset manager.
I haven't yet had time to check the access policies of the new VMA
offset manager, but anything that is identical or stricter than the
current vmwgfx verify_access() would be fine. If it's stricter however,
we need to double-check backwards user-space compatibility.
>> We also need to make vmw_user_dmabuf_reference()
>> correctly increase the vma-allow counter, but it is unused so remove it
>> instead.
IIRC this function or a derivative thereof is used heavily in an
upcoming version driver, so if possible, please add a corrected version
rather than remove the (currently) unused code. This will trigger a
merge error and the upcoming code can be more easily corrected.
>>
>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Just as a hint, this patch would allow to remove the
> "->access_verify()" callback in vmwgfx. No other driver uses it,
> afaik. I will try to add this in v2.
>
> Regards
> David
>
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29 +++++++++++++++++------------
>> 1 file changed, 17 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>> index 0e67cf4..4d3f0ae 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>> @@ -499,6 +499,12 @@ int vmw_dmabuf_alloc_ioctl(struct drm_device *dev, void *data,
>> if (unlikely(ret != 0))
>> goto out_no_dmabuf;
>>
>> + ret = drm_vma_node_allow(&dma_buf->base.vma_node, file_priv->filp);
>> + if (ret) {
>> + vmw_dmabuf_unreference(&dma_buf);
>> + goto out_no_dmabuf;
>> + }
>> +
>> rep->handle = handle;
>> rep->map_handle = drm_vma_node_offset_addr(&dma_buf->base.vma_node);
>> rep->cur_gmr_id = handle;
>> @@ -517,7 +523,18 @@ int vmw_dmabuf_unref_ioctl(struct drm_device *dev, void *data,
>> {
>> struct drm_vmw_unref_dmabuf_arg *arg =
>> (struct drm_vmw_unref_dmabuf_arg *)data;
>> + struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
>> + struct vmw_dma_buffer *dma_buf;
>> + int ret;
>> +
>> + ret = vmw_user_dmabuf_lookup(tfile, arg->handle, &dma_buf);
>> + if (ret)
>> + return -EINVAL;
>>
>> + drm_vma_node_revoke(&dma_buf->base.vma_node, file_priv->filp);
>> + vmw_dmabuf_unreference(&dma_buf);
>> +
>> + /* FIXME: is this equivalent to vmw_dmabuf_unreference(dma_buf)? */
No. A ttm ref object is rather similar to a generic GEM object, only
that it's generic in the sense that it is not restricted to buffers, and
can make any desired object visible to user-space. So translated the
below code removes a reference that the arg->handle holds on the "gem"
object, potentially destroying the whole object in which the "gem"
object is embedded.
>> return ttm_ref_object_base_unref(vmw_fpriv(file_priv)->tfile,
>> arg->handle,
>> TTM_REF_USAGE);
>> @@ -551,18 +568,6 @@ int vmw_user_dmabuf_lookup(struct ttm_object_file *tfile,
>> return 0;
>> }
>>
>> -int vmw_user_dmabuf_reference(struct ttm_object_file *tfile,
>> - struct vmw_dma_buffer *dma_buf)
>> -{
>> - struct vmw_user_dma_buffer *user_bo;
>> -
>> - if (dma_buf->base.destroy != vmw_user_dmabuf_destroy)
>> - return -EINVAL;
>> -
>> - user_bo = container_of(dma_buf, struct vmw_user_dma_buffer, dma);
>> - return ttm_ref_object_add(tfile, &user_bo->base, TTM_REF_USAGE, NULL);
>> -}
>> -
>> /*
>> * Stream management
>> */
>> --
>> 1.8.3.4
>>
Otherwise looks OK to me.
Thanks,
Thomas
next prev parent reply other threads:[~2013-08-14 17:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-13 19:38 [PATCH 00/16] DRM VMA Access Management David Herrmann
2013-08-13 19:38 ` [PATCH 01/16] drm/vma: add access management helpers David Herrmann
2013-08-13 19:38 ` [PATCH 02/16] drm/ast: implement mmap access managament David Herrmann
2013-08-13 19:38 ` [PATCH 03/16] drm/cirrus: " David Herrmann
2013-08-13 19:38 ` [PATCH 04/16] drm/mgag200: " David Herrmann
2013-08-13 19:38 ` [PATCH 05/16] drm/nouveau: " David Herrmann
2013-08-13 19:38 ` [PATCH 06/16] drm/radeon: " David Herrmann
2013-08-13 19:38 ` [PATCH 07/16] drm/qxl: " David Herrmann
2013-08-13 19:38 ` [PATCH 08/16] drm/vmwgfx: " David Herrmann
2013-08-13 21:44 ` David Herrmann
2013-08-14 17:35 ` Thomas Hellstrom [this message]
2013-08-16 13:19 ` David Herrmann
2013-08-16 15:33 ` Thomas Hellstrom
2013-08-16 17:01 ` David Herrmann
2013-08-16 17:27 ` Thomas Hellstrom
2013-08-13 19:38 ` [PATCH 09/16] drm/ttm: prevent mmap access to unauthorized users David Herrmann
2013-08-13 19:38 ` [PATCH 10/16] drm/gem: implement mmap access management David Herrmann
2013-08-13 21:05 ` Daniel Vetter
2013-08-23 11:14 ` David Herrmann
2013-08-13 19:38 ` [PATCH 11/16] drm/i915: enable GEM " David Herrmann
2013-08-13 19:38 ` [PATCH 12/16] drm/exynos: " David Herrmann
2013-08-13 19:38 ` [PATCH 13/16] drm/gma500: " David Herrmann
2013-08-13 19:38 ` [PATCH 14/16] drm/omap: " David Herrmann
2013-08-13 19:46 ` Rob Clark
2013-08-13 19:38 ` [PATCH 15/16] drm/udl: " David Herrmann
2013-08-13 19:38 ` [PATCH 16/16] drm/host1x: " David Herrmann
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=520BBFD6.8050205@vmware.com \
--to=thellstrom@vmware.com \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-graphics-maintainer@vmware.com \
/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