From: Matthew Auld <matthew.auld@intel.com> To: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org, "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Subject: [PATCH v2 1/4] drm/i915/clflush: fixup handling of cache_dirty Date: Wed, 27 Oct 2021 17:18:10 +0100 [thread overview] Message-ID: <20211027161813.3094681-1-matthew.auld@intel.com> (raw) In theory if clflush_work_create() somehow fails here, and we don't yet have mm.pages populated then we end up resetting cache_dirty, which is likely wrong, since that will potentially skip the flush-on-acquire, if it was needed. It looks like intel_user_framebuffer_dirty() can arrive here before the pages are populated. v2(Thomas): - Move setting cache_dirty out of the async portion, also add a comment for why that should still be safe. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c index f0435c6feb68..47586a8a1b73 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c @@ -109,12 +109,20 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, I915_FENCE_GFP); dma_resv_add_excl_fence(obj->base.resv, &clflush->base.dma); dma_fence_work_commit(&clflush->base); + /* + * We must have successfully populated the pages(since we are + * holding a pin on the pages as per the flush worker) to reach + * this point, which must mean we have already done the required + * flush-on-acquire, hence resetting cache_dirty here should be + * safe. + */ + obj->cache_dirty = false; } else if (obj->mm.pages) { __do_clflush(obj); + obj->cache_dirty = false; } else { GEM_BUG_ON(obj->write_domain != I915_GEM_DOMAIN_CPU); } - obj->cache_dirty = false; return true; } -- 2.26.3
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Auld <matthew.auld@intel.com> To: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org, "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Subject: [Intel-gfx] [PATCH v2 1/4] drm/i915/clflush: fixup handling of cache_dirty Date: Wed, 27 Oct 2021 17:18:10 +0100 [thread overview] Message-ID: <20211027161813.3094681-1-matthew.auld@intel.com> (raw) In theory if clflush_work_create() somehow fails here, and we don't yet have mm.pages populated then we end up resetting cache_dirty, which is likely wrong, since that will potentially skip the flush-on-acquire, if it was needed. It looks like intel_user_framebuffer_dirty() can arrive here before the pages are populated. v2(Thomas): - Move setting cache_dirty out of the async portion, also add a comment for why that should still be safe. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c index f0435c6feb68..47586a8a1b73 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c @@ -109,12 +109,20 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, I915_FENCE_GFP); dma_resv_add_excl_fence(obj->base.resv, &clflush->base.dma); dma_fence_work_commit(&clflush->base); + /* + * We must have successfully populated the pages(since we are + * holding a pin on the pages as per the flush worker) to reach + * this point, which must mean we have already done the required + * flush-on-acquire, hence resetting cache_dirty here should be + * safe. + */ + obj->cache_dirty = false; } else if (obj->mm.pages) { __do_clflush(obj); + obj->cache_dirty = false; } else { GEM_BUG_ON(obj->write_domain != I915_GEM_DOMAIN_CPU); } - obj->cache_dirty = false; return true; } -- 2.26.3
next reply other threads:[~2021-10-27 16:19 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-27 16:18 Matthew Auld [this message] 2021-10-27 16:18 ` [Intel-gfx] [PATCH v2 1/4] drm/i915/clflush: fixup handling of cache_dirty Matthew Auld 2021-10-27 16:18 ` [PATCH v2 2/4] drm/i915/clflush: disallow on discrete Matthew Auld 2021-10-27 16:18 ` [Intel-gfx] " Matthew Auld 2021-10-27 16:18 ` [PATCH v2 3/4] drm/i915: move cpu_write_needs_clflush Matthew Auld 2021-10-27 16:18 ` [Intel-gfx] " Matthew Auld 2021-10-27 16:18 ` [PATCH v2 4/4] drm/i915: stop setting cache_dirty on discrete Matthew Auld 2021-10-27 16:18 ` [Intel-gfx] " Matthew Auld 2021-10-27 18:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915/clflush: fixup handling of cache_dirty Patchwork 2021-10-27 18:12 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2021-10-27 18:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-10-28 0:59 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-10-28 8:50 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915/clflush: fixup handling of cache_dirty (rev2) Patchwork 2021-10-28 8:52 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2021-10-28 9:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-10-28 12:57 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-10-29 9:10 ` Matthew Auld 2021-10-29 16:06 ` Vudum, Lakshminarayana 2021-10-29 15:36 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211027161813.3094681-1-matthew.auld@intel.com \ --to=matthew.auld@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=thomas.hellstrom@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.