|
From: Rafael A. <ant...@gm...> - 2018-11-06 17:02:40
|
Hi,
I currently have some code that tries to use mremap to put a mapping done
by the kernel into a different address, which I previously "reserved" with
an anonymous mmap. Something like this:
void *map;
map = mmap(NULL, BLOCK_POOL_MEMFD_SIZE, PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
/* check for MAP_FAILED */
/* some code to setup BO (buffer object) */
gem_handle = anv_gem_create(pool->device, size);
void *newmap;
newmap = anv_gem_mmap(pool->device, gem_handle, 0, size, 0);
/* this fails with MAP_FAILED*/
newmap = mremap(newmap, size, size, MREMAP_MAYMOVE | MREMAP_FIXED,
map + pool->size);
My (limited) understanding is that valgrind's mremap doesn't let me remap
an address that was allocated by the ioctl, since valgrind doesn't "own"
that memory. Is there some way around this, or this is never supposed to
work?
I also tried using VALGRIND_MAKE_MEM_DEFINED on the "newmap", but that
didn't make any difference.
Thank you,
Rafael
PS: Sorry for the formatting, sending this from gmail :-/
|
|
From: Tom H. <to...@co...> - 2018-11-06 17:25:57
|
On 06/11/2018 17:02, Rafael Antognolli wrote: > My (limited) understanding is that valgrind's mremap doesn't let me > remap an address that was allocated by the ioctl, since valgrind doesn't > "own" that memory. Is there some way around this, or this is never > supposed to work? I don't see any reason why it shouldn't IF the ioctl wrapper is correctly written to update valgrind's internal state and record the mapping that it creates. If the wrapper doesn't do that then you probably have bigger problems than whether you can remap it because it will mean valgrind's state is out of sync with the kernel. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Rafael A. <ant...@gm...> - 2018-11-06 17:39:07
|
On Tue, Nov 6, 2018 at 9:25 AM Tom Hughes <to...@co...> wrote: > On 06/11/2018 17:02, Rafael Antognolli wrote: > > > My (limited) understanding is that valgrind's mremap doesn't let me > > remap an address that was allocated by the ioctl, since valgrind doesn't > > "own" that memory. Is there some way around this, or this is never > > supposed to work? > I don't see any reason why it shouldn't IF the ioctl wrapper is > correctly written to update valgrind's internal state and record > the mapping that it creates. > By that, do you mean using VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK? If so, that's already happening but no luck so far. Do you have any pointers or examples of that? > > If the wrapper doesn't do that then you probably have bigger > problems than whether you can remap it because it will mean > valgrind's state is out of sync with the kernel. > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ > |
|
From: Tom H. <to...@co...> - 2018-11-06 17:41:05
|
On 06/11/2018 17:38, Rafael Antognolli wrote: > > > On Tue, Nov 6, 2018 at 9:25 AM Tom Hughes <to...@co... > <mailto:to...@co...>> wrote: > > On 06/11/2018 17:02, Rafael Antognolli wrote: > > > My (limited) understanding is that valgrind's mremap doesn't let me > > remap an address that was allocated by the ioctl, since valgrind > doesn't > > "own" that memory. Is there some way around this, or this is never > > supposed to work? > > > I don't see any reason why it shouldn't IF the ioctl wrapper is > correctly written to update valgrind's internal state and record > the mapping that it creates. > > > By that, do you mean using VALGRIND_MALLOCLIKE_BLOCK and > VALGRIND_FREELIKE_BLOCK? If so, that's already happening but no > luck so far. No I mean that internally valgrind keeps track of the mappings in the process address space in the aspacemgr component and if a system calls creates a mapping then the post handler for that system call needs to update that. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Rafael A. <ant...@gm...> - 2018-11-06 17:50:28
|
On Tue, Nov 6, 2018 at 9:40 AM Tom Hughes <to...@co...> wrote: > On 06/11/2018 17:38, Rafael Antognolli wrote: > > > > > > On Tue, Nov 6, 2018 at 9:25 AM Tom Hughes <to...@co... > > <mailto:to...@co...>> wrote: > > > > On 06/11/2018 17:02, Rafael Antognolli wrote: > > > > > My (limited) understanding is that valgrind's mremap doesn't let > me > > > remap an address that was allocated by the ioctl, since valgrind > > doesn't > > > "own" that memory. Is there some way around this, or this is never > > > supposed to work? > > > > > > I don't see any reason why it shouldn't IF the ioctl wrapper is > > correctly written to update valgrind's internal state and record > > the mapping that it creates. > > > > > > By that, do you mean using VALGRIND_MALLOCLIKE_BLOCK and > > VALGRIND_FREELIKE_BLOCK? If so, that's already happening but no > > luck so far. > > No I mean that internally valgrind keeps track of the mappings > in the process address space in the aspacemgr component and if a > system calls creates a mapping then the post handler for that > system call needs to update that. > Oh, so this would be in valgrind's code, right? I do see VKI_DRM_IOCTL_I915_GEM_MMAP_GTT in the code, but the ioctl in question (that I can't find there) is DRM_IOCTL_I915_GEM_MMAP. So maybe with that it should work? > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ > |
|
From: Tom H. <to...@co...> - 2018-11-06 17:58:23
|
On 06/11/2018 17:50, Rafael Antognolli wrote: > Oh, so this would be in valgrind's code, right? Yes. > I do see VKI_DRM_IOCTL_I915_GEM_MMAP_GTT in the code, but the ioctl > in question (that I can't find there) is DRM_IOCTL_I915_GEM_MMAP. So > maybe with that it should work? Oh if there's no handling for it at all then it's definitely not going to work ;-) Tom -- Tom Hughes (to...@co...) http://compton.nu/ |