All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: "Guido Günther" <agx@sigxcpu.org>,
	"Russell King" <linux+etnaviv@armlinux.org.uk>,
	"Christian Gmeiner" <christian.gmeiner@gmail.com>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH 2/2] drm: etnaviv: Unmap gems on gem_close
Date: Thu, 29 Oct 2020 15:38:21 +0100	[thread overview]
Message-ID: <8a354530944e6a606212fe537c689ec20422a954.camel@pengutronix.de> (raw)
In-Reply-To: <a92da13ed190e6d49550b78dadad3c0003ef6881.1603981111.git.agx@sigxcpu.org>

Hi Guido,

Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> So far the unmap from gpu address space only happened when dropping the
> last ref in gem_free_object_unlocked, however that is skipped if there's
> still multiple handles to the same GEM object.
> 
> Since userspace (here mesa) in the case of softpin hands back the memory
> region to the pool of available GPU virtual memory closing the handle
> via DRM_IOCTL_GEM_CLOSE this can lead to etnaviv_iommu_insert_exact
> failing later since userspace thinks the vaddr is available while the
> kernel thinks it isn't making the submit fail like
> 
>   [E] submit failed: -14 (No space left on device) (etna_cmd_stream_flush:244)
> 
> Fix this by unmapping the memory via the .gem_close_object callback.
> 
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c |  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 32 +++++++++++++++++++++++++++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index a9a3afaef9a1..fdcc6405068c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -491,6 +491,7 @@ static struct drm_driver etnaviv_drm_driver = {
>  	.open               = etnaviv_open,
>  	.postclose           = etnaviv_postclose,
>  	.gem_free_object_unlocked = etnaviv_gem_free_object,
> +	.gem_close_object   = etnaviv_gem_close_object,
>  	.gem_vm_ops         = &vm_ops,
>  	.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>  	.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 4d8dc9236e5f..2226a9af0d63 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -65,6 +65,7 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op,
>  		struct drm_etnaviv_timespec *timeout);
>  int etnaviv_gem_cpu_fini(struct drm_gem_object *obj);
>  void etnaviv_gem_free_object(struct drm_gem_object *obj);
> +void etnaviv_gem_close_object(struct drm_gem_object *obj, struct drm_file *file);
>  int etnaviv_gem_new_handle(struct drm_device *dev, struct drm_file *file,
>  		u32 size, u32 flags, u32 *handle);
>  int etnaviv_gem_new_userptr(struct drm_device *dev, struct drm_file *file,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index f06e19e7be04..5aec4a23c77e 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -515,6 +515,38 @@ static const struct etnaviv_gem_ops etnaviv_gem_shmem_ops = {
>  	.mmap = etnaviv_gem_mmap_obj,
>  };
>  
> +void etnaviv_gem_close_object(struct drm_gem_object *obj, struct drm_file *unused)
> +{
> +	struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
> +	struct etnaviv_vram_mapping *mapping, *tmp;
> +
> +	/* Handle this via etnaviv_gem_free_object */
> +	if (obj->handle_count == 1)
> +		return;
> +
> +	WARN_ON(is_active(etnaviv_obj));
> +
> +	/*
> +	 * userspace wants to release the handle so we need to remove
> +	 * the mapping from the gpu's virtual address space to stay
> +	 * in sync.
> +	 */
> +	list_for_each_entry_safe(mapping, tmp, &etnaviv_obj->vram_list,
> +				 obj_node) {
> +		struct etnaviv_iommu_context *context = mapping->context;
> +
> +		WARN_ON(mapping->use);
> +
> +		if (context) {
> +			etnaviv_iommu_unmap_gem(context, mapping);
> +			etnaviv_iommu_context_put(context);

I see the issue you are trying to fix here, but this is not a viable
fix. While userspace may close the handle, the GPU may still be
processing jobs referening the BO, so we can't just unmap it from the
address space.

I think what we need to do here is waiting for the current jobs/fences
of the BO when we hit the case where userspace tries to assign a new
address to the BO. Basically wait for current jobs -> unamp from the
address space -> map at new userspace assigned address.

Regards,
Lucas

> +		}
> +
> +		list_del(&mapping->obj_node);
> +		kfree(mapping);
> +	}
> +}
> +
>  void etnaviv_gem_free_object(struct drm_gem_object *obj)
>  {
>  	struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-29 14:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1603979517.git.agx@sigxcpu.org>
2020-10-29 14:20 ` [RFC PATCH 0/2] drm: etnaviv: Unmap gems on gem_close Guido Günther
2020-10-29 14:20   ` [RFC PATCH 1/2] drm: etnaviv: Add lockdep annotations for context lock Guido Günther
2020-10-30 14:35     ` Lucas Stach
2020-10-29 14:20   ` [RFC PATCH 2/2] drm: etnaviv: Unmap gems on gem_close Guido Günther
2020-10-29 14:38     ` Lucas Stach [this message]
2020-10-29 18:20       ` Daniel Vetter
2020-10-30  9:19         ` Lucas Stach
2020-10-30  9:33           ` Daniel Vetter
2020-10-30  9:38             ` Lucas Stach
2020-10-30 14:17           ` Guido Günther

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=8a354530944e6a606212fe537c689ec20422a954.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=agx@sigxcpu.org \
    --cc=airlied@linux.ie \
    --cc=christian.gmeiner@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=linux+etnaviv@armlinux.org.uk \
    /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.