All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Jon Bloomfield" <jon.bloomfield@intel.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michel Lespinasse" <walken@google.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH] drm/i915: Use generic_access_phys
Date: Thu, 27 May 2021 11:15:31 +0200	[thread overview]
Message-ID: <YK9jM74zAkEoSBZ3@phenom.ffwll.local> (raw)
In-Reply-To: <20210526151106.3390006-1-daniel.vetter@ffwll.ch>

On Wed, May 26, 2021 at 05:11:06PM +0200, Daniel Vetter wrote:
> Since
> 
> commit 96667f8a4382db9ed042332ca6ee165ae9b91307
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Fri Nov 27 17:41:21 2020 +0100
> 
>     mm: Close race in generic_access_phys
> 
> it is race-free and can therefore be safely used for dynamic mappings
> like we have too.
> 
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Christian König" <christian.koenig@amd.com>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: Michel Lespinasse <walken@google.com>

This turned out to be a bad idea, because we stuff normal memory into our
io mappings (how well does that work on other archs, no idea). That would
be fixable, but then again we have our issue with using multiple
inconsistent mmaps, and at that point it's probably a lost cause :-(
-Daniel

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c | 60 +++---------------------
>  1 file changed, 6 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index f6fe5cb01438..717798293044 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -414,58 +414,6 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
>  	return i915_error_to_vmf_fault(ret);
>  }
>  
> -static int
> -vm_access(struct vm_area_struct *area, unsigned long addr,
> -	  void *buf, int len, int write)
> -{
> -	struct i915_mmap_offset *mmo = area->vm_private_data;
> -	struct drm_i915_gem_object *obj = mmo->obj;
> -	struct i915_gem_ww_ctx ww;
> -	void *vaddr;
> -	int err = 0;
> -
> -	if (i915_gem_object_is_readonly(obj) && write)
> -		return -EACCES;
> -
> -	addr -= area->vm_start;
> -	if (addr >= obj->base.size)
> -		return -EINVAL;
> -
> -	i915_gem_ww_ctx_init(&ww, true);
> -retry:
> -	err = i915_gem_object_lock(obj, &ww);
> -	if (err)
> -		goto out;
> -
> -	/* As this is primarily for debugging, let's focus on simplicity */
> -	vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
> -	if (IS_ERR(vaddr)) {
> -		err = PTR_ERR(vaddr);
> -		goto out;
> -	}
> -
> -	if (write) {
> -		memcpy(vaddr + addr, buf, len);
> -		__i915_gem_object_flush_map(obj, addr, len);
> -	} else {
> -		memcpy(buf, vaddr + addr, len);
> -	}
> -
> -	i915_gem_object_unpin_map(obj);
> -out:
> -	if (err == -EDEADLK) {
> -		err = i915_gem_ww_ctx_backoff(&ww);
> -		if (!err)
> -			goto retry;
> -	}
> -	i915_gem_ww_ctx_fini(&ww);
> -
> -	if (err)
> -		return err;
> -
> -	return len;
> -}
> -
>  void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
>  {
>  	struct i915_vma *vma;
> @@ -801,14 +749,18 @@ static void vm_close(struct vm_area_struct *vma)
>  
>  static const struct vm_operations_struct vm_ops_gtt = {
>  	.fault = vm_fault_gtt,
> -	.access = vm_access,
> +#ifdef CONFIG_HAVE_IOREMAP_PROT
> +	.access = generic_access_phys
> +#endif
>  	.open = vm_open,
>  	.close = vm_close,
>  };
>  
>  static const struct vm_operations_struct vm_ops_cpu = {
>  	.fault = vm_fault_cpu,
> -	.access = vm_access,
> +#ifdef CONFIG_HAVE_IOREMAP_PROT
> +	.access = generic_access_phys
> +#endif
>  	.open = vm_open,
>  	.close = vm_close,
>  };
> -- 
> 2.31.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michel Lespinasse" <walken@google.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Use generic_access_phys
Date: Thu, 27 May 2021 11:15:31 +0200	[thread overview]
Message-ID: <YK9jM74zAkEoSBZ3@phenom.ffwll.local> (raw)
In-Reply-To: <20210526151106.3390006-1-daniel.vetter@ffwll.ch>

On Wed, May 26, 2021 at 05:11:06PM +0200, Daniel Vetter wrote:
> Since
> 
> commit 96667f8a4382db9ed042332ca6ee165ae9b91307
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Fri Nov 27 17:41:21 2020 +0100
> 
>     mm: Close race in generic_access_phys
> 
> it is race-free and can therefore be safely used for dynamic mappings
> like we have too.
> 
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Christian König" <christian.koenig@amd.com>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: Michel Lespinasse <walken@google.com>

This turned out to be a bad idea, because we stuff normal memory into our
io mappings (how well does that work on other archs, no idea). That would
be fixable, but then again we have our issue with using multiple
inconsistent mmaps, and at that point it's probably a lost cause :-(
-Daniel

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c | 60 +++---------------------
>  1 file changed, 6 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index f6fe5cb01438..717798293044 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -414,58 +414,6 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
>  	return i915_error_to_vmf_fault(ret);
>  }
>  
> -static int
> -vm_access(struct vm_area_struct *area, unsigned long addr,
> -	  void *buf, int len, int write)
> -{
> -	struct i915_mmap_offset *mmo = area->vm_private_data;
> -	struct drm_i915_gem_object *obj = mmo->obj;
> -	struct i915_gem_ww_ctx ww;
> -	void *vaddr;
> -	int err = 0;
> -
> -	if (i915_gem_object_is_readonly(obj) && write)
> -		return -EACCES;
> -
> -	addr -= area->vm_start;
> -	if (addr >= obj->base.size)
> -		return -EINVAL;
> -
> -	i915_gem_ww_ctx_init(&ww, true);
> -retry:
> -	err = i915_gem_object_lock(obj, &ww);
> -	if (err)
> -		goto out;
> -
> -	/* As this is primarily for debugging, let's focus on simplicity */
> -	vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
> -	if (IS_ERR(vaddr)) {
> -		err = PTR_ERR(vaddr);
> -		goto out;
> -	}
> -
> -	if (write) {
> -		memcpy(vaddr + addr, buf, len);
> -		__i915_gem_object_flush_map(obj, addr, len);
> -	} else {
> -		memcpy(buf, vaddr + addr, len);
> -	}
> -
> -	i915_gem_object_unpin_map(obj);
> -out:
> -	if (err == -EDEADLK) {
> -		err = i915_gem_ww_ctx_backoff(&ww);
> -		if (!err)
> -			goto retry;
> -	}
> -	i915_gem_ww_ctx_fini(&ww);
> -
> -	if (err)
> -		return err;
> -
> -	return len;
> -}
> -
>  void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
>  {
>  	struct i915_vma *vma;
> @@ -801,14 +749,18 @@ static void vm_close(struct vm_area_struct *vma)
>  
>  static const struct vm_operations_struct vm_ops_gtt = {
>  	.fault = vm_fault_gtt,
> -	.access = vm_access,
> +#ifdef CONFIG_HAVE_IOREMAP_PROT
> +	.access = generic_access_phys
> +#endif
>  	.open = vm_open,
>  	.close = vm_close,
>  };
>  
>  static const struct vm_operations_struct vm_ops_cpu = {
>  	.fault = vm_fault_cpu,
> -	.access = vm_access,
> +#ifdef CONFIG_HAVE_IOREMAP_PROT
> +	.access = generic_access_phys
> +#endif
>  	.open = vm_open,
>  	.close = vm_close,
>  };
> -- 
> 2.31.0
> 

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

  parent reply	other threads:[~2021-05-27  9:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26 15:11 [PATCH] drm/i915: Use generic_access_phys Daniel Vetter
2021-05-26 15:11 ` [Intel-gfx] " Daniel Vetter
2021-05-26 15:30 ` Daniel Vetter
2021-05-26 15:30   ` [Intel-gfx] " Daniel Vetter
2021-05-26 18:54 ` kernel test robot
2021-05-26 18:54   ` kernel test robot
2021-05-26 18:54   ` [Intel-gfx] " kernel test robot
2021-05-26 18:54   ` kernel test robot
2021-05-26 20:33 ` kernel test robot
2021-05-26 20:33   ` kernel test robot
2021-05-26 20:33   ` [Intel-gfx] " kernel test robot
2021-05-26 20:33   ` kernel test robot
2021-05-26 21:50 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use generic_access_phys (rev2) Patchwork
2021-05-26 22:19 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-05-27  9:15 ` Daniel Vetter [this message]
2021-05-27  9:15   ` [Intel-gfx] [PATCH] drm/i915: Use generic_access_phys Daniel Vetter

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=YK9jM74zAkEoSBZ3@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jon.bloomfield@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=walken@google.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.