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