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

[Eric Anholt]

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?

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?

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20090705/6180e59d/attachment.sig>