All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: rodrigosiqueiramelo@gmail.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/vkms: Add functions to map GEM backing storage
Date: Tue, 10 Jul 2018 10:00:22 +0200	[thread overview]
Message-ID: <20180710080022.GH3008@phenom.ffwll.local> (raw)
In-Reply-To: <d673210355d3c5660fd8cdb7ab7ef2def7e1976c.1531149873.git.hamohammed.sa@gmail.com>

On Mon, Jul 09, 2018 at 06:44:26PM +0300, Haneen Mohammed wrote:
> This patch add the necessary functions to map GEM
> backing memory into the kernel's virtual address space.
> 
> Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c |  2 ++
>  drivers/gpu/drm/vkms/vkms_drv.h |  5 ++++
>  drivers/gpu/drm/vkms/vkms_gem.c | 50 +++++++++++++++++++++++++++++++++
>  3 files changed, 57 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index fe93f8c17997..e48c8eeb495a 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -52,9 +52,11 @@ static struct drm_driver vkms_driver = {
>  	.driver_features	= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
>  	.release		= vkms_release,
>  	.fops			= &vkms_driver_fops,
> +
>  	.dumb_create		= vkms_dumb_create,
>  	.dumb_map_offset	= vkms_dumb_map,
>  	.gem_vm_ops		= &vkms_gem_vm_ops,
> +	.gem_free_object_unlocked = vkms_gem_free_object,

This is a separate bugfix, fixing a fairly huge memory leak. I think it'd
be good to catch this in the future, by adding a 

	else
		WARN(1, "no gem free callback, leaking memory\n");

to the end of drm_gem_object_free. Can you pls do that?

Also since this line here is a bugfix separate from the vmap support, can
you pls split it out?
>  
>  	.name			= DRIVER_NAME,
>  	.desc			= DRIVER_DESC,
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 76f1720f81a5..d339a8108d85 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -35,6 +35,7 @@ struct vkms_gem_object {
>  	struct drm_gem_object gem;
>  	struct mutex pages_lock; /* Page lock used in page fault handler */
>  	struct page **pages;
> +	void *vaddr;
>  };
>  
>  int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> @@ -58,4 +59,8 @@ int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
>  int vkms_dumb_map(struct drm_file *file, struct drm_device *dev,
>  		  u32 handle, u64 *offset);
>  
> +void vkms_gem_free_object(struct drm_gem_object *obj);
> +
> +void *vkms_gem_vmap(struct drm_gem_object *obj);
> +
>  #endif /* _VKMS_DRV_H_ */
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index 9f820f56b9e0..249855dded63 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -166,3 +166,53 @@ int vkms_dumb_map(struct drm_file *file, struct drm_device *dev,
>  
>  	return ret;
>  }
> +
> +void vkms_gem_free_object(struct drm_gem_object *obj)
> +{
> +	struct vkms_gem_object *vkms_obj = container_of(obj,
> +							struct vkms_gem_object,
> +							gem);
> +	kvfree(vkms_obj->pages);

We need to put the pages here too if ->pages exists, there's a put_pages
helper for that.

Also probably a good idea to vunmap here too.

But I think both cases (i.e. vmap not yet released and pages still around)
would indicate a bug in the vkms driver of releasing the object while it's
still in use somewhere. So maybe also add a

	WARN_ON(obj->pages);
	WARN_ON(obj->vmap);

here to make sure this doesn't happen?
-Daniel

> +	mutex_destroy(&vkms_obj->pages_lock);
> +	drm_gem_object_release(obj);
> +	kfree(vkms_obj);
> +}
> +
> +struct page **get_pages(struct vkms_gem_object *vkms_obj)
> +{
> +	struct drm_gem_object *gem_obj = &vkms_obj->gem;
> +	struct page **pages = vkms_obj->pages;
> +
> +	if (!pages) {
> +		mutex_lock(&vkms_obj->pages_lock);
> +		pages = drm_gem_get_pages(gem_obj);
> +		if (IS_ERR(pages)) {
> +			mutex_unlock(&vkms_obj->pages_lock);
> +			return pages;
> +		}
> +
> +		vkms_obj->pages = pages;
> +		mutex_unlock(&vkms_obj->pages_lock);
> +	}
> +
> +	return pages;
> +}
> +
> +void *vkms_gem_vmap(struct drm_gem_object *obj)
> +{
> +	void *vaddr = NULL;
> +	struct vkms_gem_object *vkms_obj = container_of(obj,
> +							struct vkms_gem_object,
> +							gem);
> +	unsigned int n_pages = obj->size >> PAGE_SHIFT;
> +	struct page **pages = get_pages(vkms_obj);
> +
> +	if (IS_ERR(pages)) {
> +		DRM_INFO("pages allocation failed %ld\n", PTR_ERR(pages));
> +		return vaddr;
> +	}
> +
> +	vaddr = vmap(pages, n_pages, VM_MAP, PAGE_KERNEL);
> +
> +	return vaddr;
> +}
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-07-10  8:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 15:42 [PATCH 0/4] Add infrastructure needed for CRC support Haneen Mohammed
2018-07-09 15:44 ` [PATCH 1/4] drm/vkms: Add functions to map GEM backing storage Haneen Mohammed
2018-07-10  8:00   ` Daniel Vetter [this message]
2018-07-10  8:12   ` Chris Wilson
2018-07-10 15:12     ` Haneen Mohammed
2018-07-09 15:46 ` [PATCH 2/4] drm/vkms: map/unmap buffers in [prepare/cleanup]_fb hooks Haneen Mohammed
2018-07-10  8:04   ` Daniel Vetter
2018-07-09 15:47 ` [PATCH 3/4] drm/vkms: Add atomic_helper_check_plane_state Haneen Mohammed
2018-07-10  8:07   ` Daniel Vetter
2018-07-09 15:48 ` [PATCH 4/4] drm/vkms: subclass CRTC state Haneen Mohammed
2018-07-10  8:10   ` Daniel Vetter
2018-07-10 15:13     ` Haneen Mohammed

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=20180710080022.GH3008@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=rodrigosiqueiramelo@gmail.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 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.