[Intel-gfx] [PATCH] Fix system lockup when a client tries to allocate a huge BO

[Simon Farnsworth]

Eric Anholt wrote:
> On Fri, 2009-07-03 at 15:08 +0100, Simon Farnsworth wrote:
>> From: Simon Farnsworth <simon.farnsworth at onelan.co.uk>
>>
>> Fixes bugs.fdo bug #22601
>>
>> UXA tries to back all pixmaps with BOs; we have some code that tries
>> to allocate insanely large pixmaps (30,000 by 30,000 pixels). The
>> resulting pixmap is 3,600,000,000 bytes large, which is obviously too
>> big for a BO on 32-bit.
>>
>> There were two parts to the bug; firstly, logbase2 came back with the
>> wrong answer for values that were larger than INT_MAX but less than
>> ULONG_MAX.
>>
>> Secondly, drm_intel_gem_bo_alloc_internal didn't validate the results
>> it got from logbase2. Fix this by looking for cases where the result
>> was obviously invalid, and failing fast.
> 
> We generally frown on longs because it's a recipe for 32-versus-64
> failures.  Surely you mean either unsigned int, or uint64_t, right?
> 
No, I mean unsigned long. logbase2() is a utility function called only
by drm_intel_gem_bo_alloc_internal(); this takes an unsigned long size,
and was passing it to logbase2(), which took a signed int (hence silent
truncation).

drm_intel_gem_bo_alloc_internal() takes an unsigned long, because that's
part of the exported interface to the buffer manager; I didn't feel that
changing everything related to the buffer manager was appropriate for a
small bugfix.

The result was that when I asked for a 3,600,000,000 byte BO, it
calculated logbase2 of a large negative number, got a zero, and returned
a "successful" allocation of 4096 bytes to cover a 3,600,000,000 request.

Changing logbase2() to unsigned long, to match the only callsite
prevented the truncation; I then needed to teach
drm_intel_gem_bo_alloc_internal that if it got a result such that
2^logbase(size) didn't fit in an unsigned long, it should bail.

> Anyway, we could just cap allocations at aperture size and avoid any
> trickiness.  There's no reason to allow a BO to be allocated that won't
> fit in the GPU, right?
> 
Sounds very reasonable; how do I code that?

-- 
Simon Farnsworth