[Intel-gfx] [PATCH i-g-t v2] tests/drm_import_export: Add tests for prime/flink sharing races

It is possible to race between unreference of the underlying BO and importing it from prime_fd/name. Verify that the behaviour of libdrm is consistent for prime/flink. v2: more comments in source file, dropped extra whitespace Signed-off-by: Michał Winiarski michal.winiar...@intel.com Cc: Thomas

Re: [Intel-gfx] [PATCH v3] drm/i915: Use two 32bit reads for select 64bit REG_READ ioctls

/show_bug.cgi?id=91317 Testcase: igt/gem_reg_read Tested-by: Michał Winiarski michal.winiar...@intel.com Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Michał Winiarski michal.winiar...@intel.com Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/intel_uncore.c | 26

[Intel-gfx] [PATCH v2] tests/gem_reg_read: Extend and check for valid 36b counter

(reg | 1) flag to get a proper 36b timestamp, shifting the value on x86_64 if we can't. v2: More iterations of monotonic test, comments, minor fixups (Chris) Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- tests/gem_reg_read.c | 137

[Intel-gfx] [PATCH] tests/gem_reg_read: Extend and check for valid 36b counter

to get a proper 36b timestamp, shifting the value on x86_64 if we can't. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- tests/gem_reg_read.c | 123 ++- 1 file changed, 103 insertions(+), 20

[Intel-gfx] [PATCH v3] tests/gem_reg_read: Extend and check for valid 36b counter

(reg | 1) flag to get a proper 36b timestamp, shifting the value on x86_64 if we can't. v2: More iterations of monotonic test, comments, minor fixups (Chris) v3: Skip tests if reg_read is not supported Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Michał Winiarski michal.winiar

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Only update the current userptr worker

, the worker should only overwrite the obj-userptr.work pointer if and only if it is the active one. Currently we clear it for a secondary worker with the effect that we may rarely force a second lookup. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Whole series: Tested-by: Michał Winiarski

[Intel-gfx] [PATCH v2] tests/gem_userptr_blits: subtests for MAP_FIXED mappings of regular BO

fixes, s/posix_memalign/mmap (Tvrtko), merge tests into single function, call set_tiling after get_pages, comments, GUP slowpath Signed-off-by: Michał Winiarski michal.winiar...@intel.com Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Tvrtko Ursulin tvrtko.ursu...@intel.com --- tests

[Intel-gfx] [PATCH] tests/gem_userptr_blits: subtests for MAP_FIXED mappings of regular bo

When the the memory backing the userptr object is freed by the user, it's possible to trigger recursive deadlock caused by operations done on different BO mapped in that region, triggering invalidate. Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- tests/gem_userptr_blits.c | 83

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix userptr deadlock with MAP_FIXED

On Mon, Jun 29, 2015 at 12:17:33PM +0100, Chris Wilson wrote: Michał Winiarski found a really evil way to trigger a struct_mutex deadlock with userptr. He found that if he allocated a userptr bo and then GTT mmaped another bo, or even itself, at the same address as the userptr using MAP_FIXED

[Intel-gfx] [PATCH] tests/gem_userptr_blits: Race between close and invalidate

It was possible for invalidate range start mmu notifier callback to race with releasing userptr object. If the object is released prior to taking a spinlock in the callback, we'll encounter a null pointer dereference. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Michał Winiarski

[Intel-gfx] [PATCH] drm/i915: Prevent use-after-free in invalidate_range_start callback

Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- drivers/gpu/drm/i915/i915_gem_userptr.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers

[Intel-gfx] [PATCH v2] tests/gem_userptr_blits: Race between close and invalidate

Wilson ch...@chris-wilson.co.uk Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- tests/gem_userptr_blits.c | 71 +-- 1 file changed, 69 insertions(+), 2 deletions(-) diff --git a/tests/gem_userptr_blits.c b/tests/gem_userptr_blits.c index

[Intel-gfx] [PATCH v2] drm/i915: Expose all 36-bits of TIMESTAMP register on x86_64

macros. Added comments. Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- drivers/gpu/drm/i915/intel_uncore.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 0b0f4f8

[Intel-gfx] Broken TIMESTAMP on x86_64 - how to stay compatible

shuffling bytes around and that would just break other scenarios) If not, what's your opinion on solution where we setparam from userspace, and that adjusts kernel behaviour (if param is set we use 2x32 read)? -- Michał Winiarski Intel VPG ___ Intel-gfx

[Intel-gfx] [RFC] drm/i915: Add sysfs entry for reading GPU Timestamp

of timestamp in architecture independent way (using two consecutive reads). Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- drivers/gpu/drm/i915/i915_sysfs.c | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_sysfs.c b/drivers/gpu/drm

[Intel-gfx] [PATCH] drm/i915: Add RCS General Purpose Registers to parser whitelist

These registers are used as a temporary storage by MI_MATH command when performing ALU operations. Signed-off-by: Michał Winiarski michal.winiar...@intel.com --- drivers/gpu/drm/i915/i915_cmd_parser.c | 16 drivers/gpu/drm/i915/i915_reg.h| 3 +++ 2 files changed, 19

<    2   3   4   5   6   7