[Intel-gfx] [PATCH] drm/i915: Avoid undefined behaviour of "u32 >> 32"

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-29 15:50:17)
> 
> On 29/06/2017 14:49, Chris Wilson wrote:
> > When computing a hash for looking up relcoation target handles in an
> > execbuf, we start with a large size for the hashtable and proceed to
> > reduce it until the allocation suceeds. 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 by a value the width of the operand is
> > undefined, so limit the smallest hash table we use to order 1.
> > 
> > Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to vma")
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_gem_execbuffer.c | 22 +++++++++++-----------
> >   1 file changed, 11 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 718bb75ad387..54791bcb8ccb 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -296,12 +296,8 @@ static int eb_create(struct i915_execbuffer *eb)
> >                               break;
> >               } while (--size);
> >   
> > -             if (unlikely(!eb->buckets)) {
> > -                     eb->buckets = kzalloc(sizeof(struct hlist_head),
> > -                                           GFP_TEMPORARY);
> 
> Want to maybe drop the NORETRY | NOWARN from the remaining allocation 
> now? Wasn't it recently discussed that it is to feeble in it's attempts 
> to allocate?

True that was the point of the allocate afterwards, so that we could do
it with the retry flags. Time for a respin.
-Chris