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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
