ntel-gpu-tools/tests/gem_mmap_offset_exhaustion.c
Damien Lespiau 5fa15f79d0 tests: Black list tests we don't want to run on simulation
Let's start by a small set of tests, to eventually consider running
more.

The current list should then be:

gem_mmap
gem_pread_after_blit
gem_ring_sync_loop
gem_ctx_basic
gem_pipe_control_store_loop
gem_storedw_loop_render
gem_storedw_loop_blt
gem_storedw_loop_bsd
gem_render_linear_blits
gem_tiled_blits
gem_cpu_reloc

gem_exec_nop
gem_mmap_gtt

v2 add (Daniel Vetter)
gem_exec_bad_domains
gem_exec_faulting_reloc
gem_flink
gem_reg_read
gem_reloc_overflow
gem_tiling_max_stride
prime_*

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
2013-07-18 15:49:02 +01:00

99 lines
2.7 KiB
C

/*
* Copyright © 2012 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*
* Authors:
* Daniel Vetter <daniel.vetter@ffwll.ch>
*
*/
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <assert.h>
#include <fcntl.h>
#include <inttypes.h>
#include <errno.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include "drm.h"
#include "i915_drm.h"
#include "drmtest.h"
#define OBJECT_SIZE (1024*1024)
/* Testcase: checks whether the kernel handles mmap offset exhaustion correctly
*
* Currently the kernel doesn't reap the mmap offset of purged objects, albeit
* there's nothing that prevents it ABI-wise and it helps to get out of corners
* (because drm_mm is only 32bit on 32bit archs unfortunately.
*
* Note that on 64bit machines we have plenty of address space (because drm_mm
* uses unsigned long).
*/
static void
create_and_map_bo(int fd)
{
uint32_t handle;
char *ptr;
handle = gem_create(fd, OBJECT_SIZE);
ptr = gem_mmap(fd, handle, OBJECT_SIZE, PROT_READ | PROT_WRITE);
if (!ptr) {
fprintf(stderr, "mmap failed\n");
assert(ptr);
}
/* touch it to force it into the gtt */
*ptr = 0;
/* but then unmap it again because we only have limited address space on
* 32 bit */
munmap(ptr, OBJECT_SIZE);
/* we happily leak objects to exhaust mmap offset space, the kernel will
* reap backing storage. */
gem_madvise(fd, handle, I915_MADV_DONTNEED);
}
int main(int argc, char **argv)
{
int fd, i;
drmtest_skip_on_simulation();
fd = drm_open_any();
/* we have 32bit of address space, so try to fit one MB more
* than that. */
for (i = 0; i < 4096 + 1; i++)
create_and_map_bo(fd);
close(fd);
return 0;
}