All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Document our internal limit on object size
Date: Fri, 14 Oct 2016 16:49:33 +0100	[thread overview]
Message-ID: <017fb003-da3e-83a1-91fa-b97caf103fd7@linux.intel.com> (raw)
In-Reply-To: <20161014151811.26513-1-chris@chris-wilson.co.uk>


On 14/10/2016 16:18, Chris Wilson wrote:
> In many places, we try to count pages using a 32 bit integer. That
> implies if we are asked to create an object larger than 43bits, we will
> subtly crash much later. Catch this on the boundary, and add a warning
> to remind ourselves later on our exabyte systems.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/i915_drv.h |  2 +-
>   drivers/gpu/drm/i915/i915_gem.c | 14 ++++++++++++--
>   2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fe875b27a6bf..43eb1a72f19e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3107,7 +3107,7 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj);
>   void i915_gem_object_init(struct drm_i915_gem_object *obj,
>   			 const struct drm_i915_gem_object_ops *ops);
>   struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> -						  size_t size);
> +						   u64 size);
>   struct drm_i915_gem_object *i915_gem_object_create_from_data(
>   		struct drm_device *dev, const void *data, size_t size);
>   void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fe92e28ea0a8..0d1dc04302ec 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4131,14 +4131,24 @@ static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
>   	.put_pages = i915_gem_object_put_pages_gtt,
>   };
>   
> -struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> -						  size_t size)
> +struct drm_i915_gem_object *
> +i915_gem_object_create(struct drm_device *dev, u64 size)
>   {
>   	struct drm_i915_gem_object *obj;
>   	struct address_space *mapping;
>   	gfp_t mask;
>   	int ret;
>   
> +	/* There is a prevalence of the assumption that we fit the object's
> +	 * page count inside a 32bit variable. Let's document this and catch
> +	 * if we ever need to fix it.
> +	 */
> +	if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
> +		return ERR_PTR(-E2BIG);
> +
> +	if (sizeof(size_t) < sizeof(u64) && size > INT_MAX)
> +		return ERR_PTR(-E2BIG);
> +

Shouldn't it be UINT_MAX in both cases?

We could try to future proof more maybe like 
sizeof(typeof(obj->base.size)), is typeof can be used like that? 
Something similar for sg API if possible. But then again, it could be 
better future proofing to be hardcoded like you wrote it. Yes I think so.

Regards,

Tvrtko



_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-10-14 15:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-14 15:18 [PATCH 1/2] drm/i915: Document our internal limit on object size Chris Wilson
2016-10-14 15:18 ` [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits Chris Wilson
2016-10-14 15:38   ` Tvrtko Ursulin
2016-10-14 15:43     ` Chris Wilson
2016-10-14 15:45       ` Tvrtko Ursulin
2016-10-14 15:24 ` [PATCH 1/2] drm/i915: Document our internal limit on object size Chris Wilson
2016-10-14 15:43   ` Tvrtko Ursulin
2016-10-14 15:49 ` Tvrtko Ursulin [this message]
2016-10-14 16:03   ` Chris Wilson
2016-10-14 16:08     ` Chris Wilson
2016-10-14 17:50 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork

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=017fb003-da3e-83a1-91fa-b97caf103fd7@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.