[Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

[Chris Wilson]

On Fri, Oct 14, 2016 at 04:49:33PM +0100, Tvrtko Ursulin wrote:
> 
> 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 at 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?

I've spotted a few "int page_count = obj->size / PAGE_SIZE;" so we can't
trust ourselves at all!

> 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.

I was just about to write it as obj->base.size, Let's compare!

#define overflows_type(x, T) \
	(sizeof(x) < sizeof(T) && (x) > 1 << (sizeof(T) * BITS_PER_BYTE))

  if (overflows_type(size, obj->base.size)

or

  if (overflows_type(size, size_t))

I think obj->base.size looks better from the self-documentation standpoint.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre