On Thu, Apr 23, 2015 at 12:23:17PM +0100, [email protected] wrote: > From: Tvrtko Ursulin <[email protected]> > > Using imported objects should not leak i915 vmas (and vms). > > In practice this simulates Xorg importing fbcon and leaking (or not) one vma > per Xorg startup cycle. > > v2: use low-level ioctl wrappers and bo offset to check the leak (Chris) > v3: use the flinked bo as batch (Chris) > > Signed-off-by: Tvrtko Ursulin <[email protected]> > Signed-off-by: Daniele Ceraolo Spurio <[email protected]> (v2+) > Cc: Chris Wilson <[email protected]> > Cc: Tvrtko Ursulin <[email protected]>
Bikeshedding for fun aside, Reviewed-by: Chris Wilson <[email protected]> > +static uint64_t exec_and_get_offset(int fd, uint32_t batch) > +{ > + struct drm_i915_gem_execbuffer2 execbuf; > + struct drm_i915_gem_exec_object2 exec[1]; > + uint32_t batch_data[2] = { MI_NOOP, MI_BATCH_BUFFER_END }; uint32_t buf[2] = { MI_BATCH_BUFFER_END }; > + > + gem_write(fd, batch, 0, batch_data, sizeof(batch_data)); > + > + memset(exec, 0, sizeof(exec)); > + exec[0].handle = batch; > + exec[0].relocation_count = 0; > + exec[0].relocs_ptr = 0; We just memset(0) these two, so we don't need to clear them again. > + memset(&execbuf, 0, sizeof(execbuf)); > + execbuf.buffers_ptr = (uintptr_t)exec; > + execbuf.buffer_count = 1; > + execbuf.batch_len = sizeof(batch_data); > + execbuf.flags = 0; These two can also happily disappear. > + gem_execbuf(fd, &execbuf); igt_assert_neq(exec[0].offset, -1) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
