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

[Chad Versace]

On Wed 19 Nov 2014, 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.
>
>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.

I agree with Ken.

48-bit isn't an issue that this patch is even trying to address.
This patch is trying reduce overflow errors due to sloppy userspace 
code, errors that will happen (and have happened) with pre-48-bit GPUs.