[Mesa-dev] [PATCH 2/4] i965: Fix intel_miptree_map() signature to be more 64-bit safe

[Ian Romanick]

On 11/19/2014 09:18 PM, Kenneth Graunke wrote:
> On Wednesday, November 19, 2014 02:13:03 PM Ian Romanick wrote:
>> On 11/18/2014 09:11 PM, Chad Versace wrote:
>>> This patch should diminish the likelihood of pointer arithmetic overflow
>>> bugs, like the one fixed by b69c7c5dac.
>>>
>>> Change the type of parameter 'out_stride' from int to ptrdiff_t. The
>>> logic is that if you call intel_miptree_map() and use the value of
>>> 'out_stride', then you must be doing pointer arithmetic on 'out_ptr'.
>>> Using ptrdiff_t instead of int should make a little bit harder to hit
>>> overflow bugs.
>>
>> So... we talked about this a little bit on Monday, and I don't think we
>> ever had a conclusion.  What happens if you have a 32-bit application
>> running on a platform with 48-bit GPU address space?
> 
> CC'ing Ben, who knows all the gory details.
> 
> I don't really understand the problem - the GPU uses 48-bit addressing, and
> can access more than 4G...but we're talking about map, which makes a buffer
> available in an application's virtual address space...which is 32-bit in your
> example.  It should always be placed at a < 4GB virtual address and work out
> fine.

Right.  I must have been having a senior moment or something.

> That said, I don't think the kernel ever uses >= 4GB address spaces today.
> Ben wrote 4GGGTT support and had both kernel and userspace patches to make
> it work, but I don't think it ever actually landed.  I'm pretty sure
> shipping userspace is not quite 48-bit safe - there are a few buffers that
> have to be placed < 4GB (some hardware packets only take 32-bit addresses
> still), and I don't think any software is in place to make that happen.
> 
> --Ken