drm/i915: Avoid undefined behaviour of "u32 >> 32"
authorChris Wilson <chris@chris-wilson.co.uk>
Thu, 29 Jun 2017 15:04:25 +0000 (16:04 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Thu, 29 Jun 2017 15:34:43 +0000 (16:34 +0100)
commit4d470f7359c4bf22518baa30700ad45649371a22
tree1fd262e5e117e7c53701b1705df082345af306ce
parent886015a0ad43c7fc034b23ea4614ba39162f9ddd
drm/i915: Avoid undefined behaviour of "u32 >> 32"

When computing a hash for looking up relocation target handles in an
execbuf, we start with a large size for the hashtable and proceed to
halve it until the allocation succeeds. The final attempt is with an
order of 0 (i.e. a single element). This means that we then pass bits=0
to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
element. Right shifting a value by the width of the operand is
undefined, so limit the smallest hash table we use to order 1.

v2: Keep the retry allocation flag for the final pass

Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to vma")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629150425.27508-1-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/i915_gem_execbuffer.c