[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm()

== Series Details == Series: drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm() URL : https://patchwork.freedesktop.org/series/52910/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5194 -> Patchwork_10892 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm()

On 2018.11.23 10:22:19 +0300, Dan Carpenter wrote: > We need to use the _safe() version of this macro so that we don't > dereference "pos" when it is freed. > Thanks, Dan. I've already merged one same fix from Chris for this found by smatch. > Fixes: bc0686ff5fad ("drm/i915/gvt: support

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm()

== Series Details == Series: drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm() URL : https://patchwork.freedesktop.org/series/52910/ State : warning == Summary == $ dim checkpatch origin/drm-tip a74710452c2c drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm() -:25:

[Intel-gfx] [PATCH] drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm()

We need to use the _safe() version of this macro so that we don't dereference "pos" when it is freed. Fixes: bc0686ff5fad ("drm/i915/gvt: support inconsecutive partial gtt entry write") Signed-off-by: Dan Carpenter --- drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[Intel-gfx] ✗ Fi.CI.IGT: failure for RFC: mmu notifier debug checks

== Series Details == Series: RFC: mmu notifier debug checks URL : https://patchwork.freedesktop.org/series/52890/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5191_full -> Patchwork_10888_full = == Summary - FAILURE == Serious unknown changes coming with

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/Makefile between commit: 2bb42410b1bd ("drm: Remove drm_global.{c,h} v2") from the drm tree and commit: c6fdea6e1a19 ("drm: Merge drm_info.c into drm_debugfs.c") from the drm-misc tree. I fixed

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse

Merged to drm-intel-next-queued, thanks for the reviews Ville and Rodrigo. On Thu, 2018-11-22 at 03:23 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v5,1/6] drm/i915: Avoid a full port > detection in the first eDP short pulse > URL :

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev4)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev4) URL : https://patchwork.freedesktop.org/series/52887/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5191 -> Patchwork_10891 = == Summary - FAILURE ==

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev4)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev4) URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Flush the

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev4)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev4) URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim checkpatch origin/drm-tip 821c90f3f442 drm/i915/selftests: Flush the test object on

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev3)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev3) URL : https://patchwork.freedesktop.org/series/52887/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5191 -> Patchwork_10890 = == Summary - FAILURE ==

[Intel-gfx] [PATCH v4] drm/i915/selftests: Check MI_STORE_DWORD_IMM coherency

We use MI_STORE_DWORD_IMM internally (e.g. for gpu relocations) and so require that its are writes flushed to memory on demand. Verify this with a selftest. v2: Use variable lengths of submission queues as the delay between submit and checking is also crucially important for error detection. v3:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev3)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev3) URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Flush the

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev3)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev3) URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim checkpatch origin/drm-tip d8c8001692a3 drm/i915/selftests: Flush the test object on

[Intel-gfx] [PATCH v3] drm/i915/selftests: Check MI_STORE_DWORD_IMM coherency

We use MI_STORE_DWORD_IMM internally (e.g. for gpu relocations) and so require that its are writes flushed to memory on demand. Verify this with a selftest. v2: Use variable lengths of submission queues as the delay between submit and checking is also crucially important for error detection.

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev2) URL : https://patchwork.freedesktop.org/series/52887/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5191 -> Patchwork_10889 = == Summary - FAILURE ==

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev2) URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Flush the

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation (rev2) URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim checkpatch origin/drm-tip 309ac28a36a0 drm/i915/selftests: Flush the test object on

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier

== Series Details == Series: series starting with [1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier URL : https://patchwork.freedesktop.org/series/52882/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5189_full -> Patchwork_10885_full = ==

[Intel-gfx] [PATCH v2] drm/i915/selftests: Check MI_STORE_DWORD_IMM coherency

We use MI_STORE_DWORD_IMM internally (e.g. for gpu relocations) and so require that its are writes flushed to memory on demand. Verify this with a selftest. v2: Use variable lengths of submission queues as the delay between submit and checking is also crucially important for error detection.

Re: [Intel-gfx] [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

Am 22.11.18 um 17:51 schrieb Daniel Vetter: > We need to make sure implementations don't cheat and don't have a > possible schedule/blocking point deeply burried where review can't > catch it. > > I'm not sure whether this is the best way to make sure all the > might_sleep() callsites trigger, and

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

Am 22.11.18 um 17:51 schrieb Daniel Vetter: > Just a bit of paranoia, since if we start pushing this deep into > callchains it's hard to spot all places where an mmu notifier > implementation might fail when it's not allowed to. > > Cc: Andrew Morton > Cc: Michal Hocko > Cc: "Christian König" >

[Intel-gfx] ✓ Fi.CI.BAT: success for RFC: mmu notifier debug checks

== Series Details == Series: RFC: mmu notifier debug checks URL : https://patchwork.freedesktop.org/series/52890/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5191 -> Patchwork_10888 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC: mmu notifier debug checks

== Series Details == Series: RFC: mmu notifier debug checks URL : https://patchwork.freedesktop.org/series/52890/ State : warning == Summary == $ dim checkpatch origin/drm-tip a2676e3168ac mm: Check if mmu notifier callbacks are allowed to fail -:31: ERROR:SPACING: space required after that

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/selftests: Flush the test object on creation

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation URL : https://patchwork.freedesktop.org/series/52887/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5189 -> Patchwork_10887 = == Summary - FAILURE == Serious

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Flush the test

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation URL : https://patchwork.freedesktop.org/series/52887/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3ca097048a16 drm/i915/selftests: Flush the test object on creation

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

Quoting Daniel Vetter (2018-11-22 16:51:04) > Just a bit of paranoia, since if we start pushing this deep into > callchains it's hard to spot all places where an mmu notifier > implementation might fail when it's not allowed to. Most callers could handle the failure correctly. It looks like the

[Intel-gfx] [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

We need to make sure implementations don't cheat and don't have a possible schedule/blocking point deeply burried where review can't catch it. I'm not sure whether this is the best way to make sure all the might_sleep() callsites trigger, and it's a bit ugly in the code flow. But it gets the job

[Intel-gfx] [PATCH 3/3] mm, notifier: Add a lockdep map for invalidate_range_start

This is a similar idea to the fs_reclaim fake lockdep lock. It's fairly easy to provoke a specific notifier to be run on a specific range: Just prep it, and then munmap() it. A bit harder, but still doable, is to provoke the mmu notifiers for all the various callchains that might lead to them.

[Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

Just a bit of paranoia, since if we start pushing this deep into callchains it's hard to spot all places where an mmu notifier implementation might fail when it's not allowed to. Cc: Andrew Morton Cc: Michal Hocko Cc: "Christian König" Cc: David Rientjes Cc: Daniel Vetter Cc: "Jérôme Glisse"

[Intel-gfx] [PATCH 0/3] RFC: mmu notifier debug checks

Hi all, We're having some good fun with the i915 mmu notifier (it deadlocks), and I think it'd be very useful to have a bunch more runtime debug checks to catch screw-ups. I'm also working on some lockdep improvements in gpu code (better annotations and stuff like that). Together with this

[Intel-gfx] [PATCH 3/3] drm/i915: Avoid using MI_STORE_DWORD_IMM on vecs

It turns out that our MI_FLUSH_DW we perform after each batch is not sufficient to flush MI_STORE_DWORD_IMM to memory. Of course, this raises the concern that MI_FLUSH_DW may not be flushing anything on vecs, but for the moment we have to neuter our own use of store-dw. I have tried: 8x

[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Check MI_STORE_DWORD_IMM coherency

We use MI_STORE_DWORD_IMM internally (e.g. for gpu relocations) and so require that its are writes flushed to memory on demand. Verify this with a selftest. Signed-off-by: Chris Wilson --- .../drm/i915/selftests/i915_gem_coherency.c | 454 ++ 1 file changed, 454 insertions(+)

[Intel-gfx] [PATCH 1/3] drm/i915/selftests: Flush the test object on creation

Move the flush from before emitting the gpu_fill request to the object's creation to avoid forcing a stall on each write. The only stall should now be after all the writes have been queued and we want to read the results. Signed-off-by: Chris Wilson ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/13] locking/lockdep: restore cross-release checks (rev4)

== Series Details == Series: series starting with [01/13] locking/lockdep: restore cross-release checks (rev4) URL : https://patchwork.freedesktop.org/series/52167/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC

[Intel-gfx] [PATCH] HAX FOR CI: Enable cross-release

Only way to convince our CI to enable stuff that's new and defaulting to off. Obviously not for merging. v2: Also enable fullstack backtraces. v3: Try to chase this elusive stack trace corruption CI is seeing. Signed-off-by: Daniel Vetter --- kernel/locking/lockdep.c | 13 +

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier

== Series Details == Series: series starting with [1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier URL : https://patchwork.freedesktop.org/series/52882/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5189 -> Patchwork_10885 = == Summary -

[Intel-gfx] Updated drm-intel-testing

Hi all, It may be about time we update the process around drm-intel-testing, but here goes anyway... The following changes tagged drm-intel-testing-2018-11-22: drm-intel-next-2018-11-22: Changes outside i915: - Connector property to limit max bpc (Radhakrishna) - Fix LPE audio runtime PM and

Re: [Intel-gfx] [PATCH 1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier

Op 22-11-18 om 15:34 schreef Ville Syrjala: > From: Ville Syrjälä > > Consider the following scenario: > 1. nonblocking enable crtc > 2. wait for the event > 3. nonblocking disable crtc > > On i915 this can lead to a spurious -EBUSY from step 3 on > account of non-enabled planes getting the

[Intel-gfx] [PATCH 1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier

From: Ville Syrjälä Consider the following scenario: 1. nonblocking enable crtc 2. wait for the event 3. nonblocking disable crtc On i915 this can lead to a spurious -EBUSY from step 3 on account of non-enabled planes getting the fake_commit in step 1 and we don't complete the fake_commit->

[Intel-gfx] [PATCH 2/2] drm/atomic-helper: WARN if fake_commit->hw_done is not completed as expected

From: Ville Syrjälä For real commits we WARN if ->hw_done hasn't been completed by the time drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for the fake commit. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 4 +++- 1 file changed, 3 insertions(+),

Re: [Intel-gfx] [PATCH 2/2] gpu/i915: use HMM mirror for userptr buffer object.

On Thu, Nov 22, 2018 at 03:59:50PM +0200, Joonas Lahtinen wrote: > Hi Jerome, > > Bit late reply, but here goes :) > > We're working quite hard to avoid pinning any pages unless they're in > the GPU page tables. And when they are in the GPU page tables, they must > be pinned for whole of that

Re: [Intel-gfx] [PATCH 2/2] gpu/i915: use HMM mirror for userptr buffer object.

Hi Jerome, Bit late reply, but here goes :) We're working quite hard to avoid pinning any pages unless they're in the GPU page tables. And when they are in the GPU page tables, they must be pinned for whole of that duration, for the reason that our GPUs can not take a fault. And to avoid

[Intel-gfx] [bug report] i915/dp/fec: Cache the FEC_CAPABLE DPCD register

Hello Anusha Srivatsa, The patch 08cadae8e157: "i915/dp/fec: Cache the FEC_CAPABLE DPCD register" from Nov 1, 2018, leads to the following static checker warning: drivers/gpu/drm/i915/intel_dp.c:3846 intel_dp_get_dsc_sink_cap() warn: inconsistent indenting

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/selftests: Flush the test object on creation

Quoting Patchwork (2018-11-22 12:42:24) > == Series Details == > > Series: series starting with [1/3] drm/i915/selftests: Flush the test object > on creation > URL : https://patchwork.freedesktop.org/series/52875/ > State : failure > > == Summary == > > = CI Bug Log - changes from

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/selftests: Flush the test object on creation

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation URL : https://patchwork.freedesktop.org/series/52875/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5186 -> Patchwork_10884 = == Summary - FAILURE == Serious

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation URL : https://patchwork.freedesktop.org/series/52875/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Flush the test

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/selftests: Flush the test object on creation

== Series Details == Series: series starting with [1/3] drm/i915/selftests: Flush the test object on creation URL : https://patchwork.freedesktop.org/series/52875/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5e991e45460d drm/i915/selftests: Flush the test object on creation

[Intel-gfx] [PATCH 3/3] drm/i915: Avoid using MI_STORE_DWORD_IMM on vecs

It runs out that our MI_FLUSH_DW we perform after each batch is not sufficient to flush MI_STORE_DWORD_IMM to memory. Of course, this raises the concern that MI_FLUSH_DW may not be flushing anything on vecs, but for the moment we have to neuter our own use of store-dw. I have tried: 8x

[Intel-gfx] [PATCH 1/3] drm/i915/selftests: Flush the test object on creation

Move the flush from before emitting the gpu_fill request to the object's creation to avoid forcing a stall on each write. The only stall should be after all the writes have been queued and we want to read the results. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/selftests/i915_gem_context.c

[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Check MI_STORE_DWORD_IMM coherency

We use MI_STORE_DWORD_IMM internally (e.g. for gpu relocations) and so require that it its writes flushed to memory on demand. Verify this with a selftest. Signed-off-by: Chris Wilson --- .../drm/i915/selftests/i915_gem_coherency.c | 454 ++ 1 file changed, 454 insertions(+)

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, Here's the -fixes for 4.20-rc4. Stuck backlight/flickering fix for DSI screen and GPU hang fix for SNB are the main user visible ones. Then two more fixes to prevent GPU hangs in more rare scenarios. Regards, Joonas *** drm-intel-fixes-2018-11-22: - Fix for fastboot DSI panel boot

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Synchronize hpd work in i915_hpd_storm_ctl_show()

== Series Details == Series: drm/i915: Synchronize hpd work in i915_hpd_storm_ctl_show() URL : https://patchwork.freedesktop.org/series/52796/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5175_full -> Patchwork_10872_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: avoid rebuilding i915_gpu_error.o on version string updates

Merged now, thanks for the patch and reviews. Quoting Patchwork (2018-11-22 02:05:03) > == Series Details == > > Series: drm/i915: avoid rebuilding i915_gpu_error.o on version string updates > URL : https://patchwork.freedesktop.org/series/52822/ > State : success > > == Summary == > > = CI

Re: [Intel-gfx] [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.

On Mon, Oct 22, 2018 at 10:53:22PM +0530, Arun KS wrote: > Remove managed_page_count_lock spinlock and instead use atomic > variables. > > Suggested-by: Michal Hocko > Suggested-by: Vlastimil Babka > Signed-off-by: Arun KS > > --- > As discussed here, >

Re: [Intel-gfx] [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere

On 12/11/2018 15:01, Maarten Lankhorst wrote: > We already have __drm_atomic_helper_connector_reset() and > __drm_atomic_helper_plane_reset(), extend this to crtc as well. > > Most drivers already have a gpu reset hook, correct it. > Nouveau already implemented its own

Re: [Intel-gfx] [PATCH v2 0/7] Make GEN macros more similar

On 21/11/2018 22:19, Rodrigo Vivi wrote: On Mon, Nov 19, 2018 at 02:20:55PM -0800, Lucas De Marchi wrote: On Thu, Nov 08, 2018 at 11:23:46AM +, Tvrtko Ursulin wrote: On 08/11/2018 00:57, Lucas De Marchi wrote: On Wed, Nov 07, 2018 at 10:05:19AM +, Tvrtko Ursulin wrote: On

Re: [Intel-gfx] [PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count

On Wed, Nov 21, 2018 at 06:46:57PM +0200, Ville Syrjälä wrote: > On Wed, Nov 21, 2018 at 05:22:49PM +0100, Daniel Vetter wrote: > > On Wed, Nov 21, 2018 at 5:16 PM Ville Syrjälä > > wrote: > > > > > > On Wed, Nov 21, 2018 at 04:19:36PM +0100, Daniel Vetter wrote: > > > > On Wed, Nov 21, 2018 at