i965: Use VALGRIND_MAKE_MEM_x in place of MALLOCLIKE/FREELIKE
authorChris Wilson <chris@chris-wilson.co.uk>
Tue, 11 Jul 2017 15:54:25 +0000 (16:54 +0100)
committerKenneth Graunke <kenneth@whitecape.org>
Tue, 11 Jul 2017 21:07:47 +0000 (14:07 -0700)
commitcead51a0c63df1613f9f6400657597679126024c
treed04a7951078bbef5f0fb3146454316fd110624e7
parent314879f7fec07cedb5263681173a22d522a8ac9a
i965: Use VALGRIND_MAKE_MEM_x in place of MALLOCLIKE/FREELIKE

Valgrind doesn't actually implement VALGRIND_FREELIKE_BLOCK as the
exact inverse of VALGRIND_MALLOCLIKE_BLOCK. It makes the block
inaccessible, but still leaves it defined in its allocation tracker i.e.
it will report the mmap as lost despite the call to FREELIKE!

Instead of treating the mmap as an allocation, treat it as changing the
access bits upon the memory, i.e. that it becomes defined (because of
the buffer objects always contain valid content from the user's
perspective) upon mmap and inaccessible upon munmap. This makes memcheck
happy without leaving it thinking there is a very large leak.

Finally for consistency, we treat all the mmap/munmap paths the same
even though valgrind can intercept the regular mmap used for GTT. We
could move this in the drm_mmap/drm_munmap macros, but that quickly
looks ugly given the desire for those to support different OSes, but I
didn't try that hard!

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
src/mesa/drivers/dri/i965/brw_bufmgr.c