* [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
@ 2022-03-31 15:20 ` Daniel Vetter
0 siblings, 0 replies; 80+ messages in thread
From: Daniel Vetter @ 2022-03-31 15:20 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Michel Dänzer, Kazlauskas, Nicholas,
Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski,
Intel Graphics Development
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.
For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
Inspired by an amdgpu bug report.
v2: Drop RFC, I think with amdgpu converted over to use
atomic_async_check/commit done in
commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Wed Dec 5 14:59:07 2018 -0500
drm/amd/display: Add fast path for cursor plane updates
we don't have any driver anymore where we have userspace expecting
solid legacy cursor support _and_ they are using the atomic helpers in
their fully glory. So we can retire this.
v3: Paper over msm and i915 regression. The complete_all is the only
thing missing afaict.
v4: Fixup i915 fixup ...
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Cc: Maxime Ripard <maxime@cerno.tech>
Tested-by: Maxime Ripard <maxime@cerno.tech>
Cc: mikita.lipski@amd.com
Cc: Michel Dänzer <michel@daenzer.net>
Cc: harry.wentland@amd.com
Cc: Rob Clark <robdclark@gmail.com>
Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -------------
drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++
drivers/gpu/drm/msm/msm_atomic.c | 2 ++
3 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 9603193d2fa1..a2899af82b4a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
int i, ret;
unsigned int crtc_mask = 0;
- /*
- * Legacy cursor ioctls are completely unsynced, and userspace
- * relies on that (by doing tons of cursor updates).
- */
- if (old_state->legacy_cursor_update)
- return;
-
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) {
if (!new_crtc_state->active)
continue;
@@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
continue;
}
- /* Legacy cursor updates are fully unsynced. */
- if (state->legacy_cursor_update) {
- complete_all(&commit->flip_done);
- continue;
- }
-
if (!new_crtc_state->event) {
commit->event = kzalloc(sizeof(*commit->event),
GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index d2abe0e430bf..6ca5a6e7703b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref);
return ret;
}
+
+ /*
+ * FIXME: Cut over to (async) commit helpers instead of hand-rolling
+ * everything.
+ */
+ if (state->base.legacy_cursor_update) {
+ struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc *crtc;
+ int i;
+
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
+ complete_all(&new_crtc_state->uapi.commit->flip_done);
+ }
+
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 1686fbb611fd..b3cfabebe5d6 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
/* async updates are limited to single-crtc updates: */
WARN_ON(crtc_mask != drm_crtc_mask(async_crtc));
+ complete_all(&async_crtc->state->commit->flip_done);
+
/*
* Start timer if we don't already have an update pending
* on this crtc:
--
2.34.1
^ permalink raw reply related [flat|nested] 80+ messages in thread* [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-03-31 15:20 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-03-31 15:20 UTC (permalink / raw) To: DRI Development Cc: Daniel Vetter, Michel Dänzer, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, harry.wentland, Intel Graphics Development The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit hooks. Support for that for msm and vc4 landed. nouveau and i915 have their own commit routines, doing something similar. For everyone else it's probably better to remove the use-after-free bug, and encourage folks to use the async support instead. The affected drivers which register a legacy cursor plane and don't either use the new async stuff or their own commit routine are: amdgpu, atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. Inspired by an amdgpu bug report. v2: Drop RFC, I think with amdgpu converted over to use atomic_async_check/commit done in commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Date: Wed Dec 5 14:59:07 2018 -0500 drm/amd/display: Add fast path for cursor plane updates we don't have any driver anymore where we have userspace expecting solid legacy cursor support _and_ they are using the atomic helpers in their fully glory. So we can retire this. v3: Paper over msm and i915 regression. The complete_all is the only thing missing afaict. v4: Fixup i915 fixup ... References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard <maxime@cerno.tech> Tested-by: Maxime Ripard <maxime@cerno.tech> Cc: mikita.lipski@amd.com Cc: Michel Dänzer <michel@daenzer.net> Cc: harry.wentland@amd.com Cc: Rob Clark <robdclark@gmail.com> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ drivers/gpu/drm/msm/msm_atomic.c | 2 ++ 3 files changed, 16 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 9603193d2fa1..a2899af82b4a 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, int i, ret; unsigned int crtc_mask = 0; - /* - * Legacy cursor ioctls are completely unsynced, and userspace - * relies on that (by doing tons of cursor updates). - */ - if (old_state->legacy_cursor_update) - return; - for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { if (!new_crtc_state->active) continue; @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } - /* Legacy cursor updates are fully unsynced. */ - if (state->legacy_cursor_update) { - complete_all(&commit->flip_done); - continue; - } - if (!new_crtc_state->event) { commit->event = kzalloc(sizeof(*commit->event), GFP_KERNEL); diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index d2abe0e430bf..6ca5a6e7703b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); return ret; } + + /* + * FIXME: Cut over to (async) commit helpers instead of hand-rolling + * everything. + */ + if (state->base.legacy_cursor_update) { + struct intel_crtc_state *new_crtc_state; + struct intel_crtc *crtc; + int i; + + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) + complete_all(&new_crtc_state->uapi.commit->flip_done); + } + intel_shared_dpll_swap_state(state); intel_atomic_track_fbs(state); diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 1686fbb611fd..b3cfabebe5d6 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) /* async updates are limited to single-crtc updates: */ WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); + complete_all(&async_crtc->state->commit->flip_done); + /* * Start timer if we don't already have an update pending * on this crtc: -- 2.34.1 ^ permalink raw reply related [flat|nested] 80+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/atomic-helpers: remove legacy_cursor_update hacks 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter (?) @ 2022-03-31 19:35 ` Patchwork -1 siblings, 0 replies; 80+ messages in thread From: Patchwork @ 2022-03-31 19:35 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx == Series Details == Series: drm/atomic-helpers: remove legacy_cursor_update hacks URL : https://patchwork.freedesktop.org/series/102028/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2d13341ec246 drm/atomic-helpers: remove legacy_cursor_update hacks -:29: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates")' #29: commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 -:45: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #45: References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ -:125: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>' total: 1 errors, 2 warnings, 0 checks, 53 lines checked ^ permalink raw reply [flat|nested] 80+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/atomic-helpers: remove legacy_cursor_update hacks 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter (?) (?) @ 2022-03-31 20:10 ` Patchwork -1 siblings, 0 replies; 80+ messages in thread From: Patchwork @ 2022-03-31 20:10 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 8258 bytes --] == Series Details == Series: drm/atomic-helpers: remove legacy_cursor_update hacks URL : https://patchwork.freedesktop.org/series/102028/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11436 -> Patchwork_22750 ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with Patchwork_22750 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22750, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/index.html Participating hosts (45 -> 40) ------------------------------ Additional (1): fi-cml-u2 Missing (6): fi-kbl-soraka shard-tglu bat-dg2-8 bat-adlm-1 fi-bsw-cyan bat-jsl-2 Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_22750: ### IGT changes ### #### Possible regressions #### * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-cml-u2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html Known issues ------------ Here are the changes found in Patchwork_22750 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_exec_fence@basic-busy@bcs0: - fi-cml-u2: NOTRUN -> [SKIP][2] ([i915#1208]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@gem_exec_fence@basic-busy@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-cml-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@gem_huc_copy@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-cml-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@gem_lmem_swapping@parallel-random-engines.html * igt@kms_busy@basic@flip: - fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11436/fi-tgl-u2/igt@kms_busy@basic@flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-tgl-u2/igt@kms_busy@basic@flip.html * igt@kms_chamelium@dp-hpd-fast: - fi-cml-u2: NOTRUN -> [SKIP][7] ([fdo#109284] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@kms_chamelium@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-cml-u2: NOTRUN -> [SKIP][8] ([fdo#109278]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-cml-u2: NOTRUN -> [SKIP][9] ([fdo#109285]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@kms_force_connector_basic@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: NOTRUN -> [DMESG-WARN][10] ([i915#4269]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cml-u2: NOTRUN -> [SKIP][11] ([fdo#109278] / [i915#533]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-cml-u2/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html #### Possible fixes #### * igt@i915_pm_rps@basic-api: - {fi-jsl-1}: [DMESG-WARN][12] ([i915#5482]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11436/fi-jsl-1/igt@i915_pm_rps@basic-api.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-jsl-1/igt@i915_pm_rps@basic-api.html * igt@i915_selftest@live@hangcheck: - bat-dg1-6: [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11436/bat-dg1-6/igt@i915_selftest@live@hangcheck.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/bat-dg1-6/igt@i915_selftest@live@hangcheck.html * igt@kms_busy@basic@flip: - {bat-dg2-9}: [DMESG-WARN][16] ([i915#5291]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11436/bat-dg2-9/igt@kms_busy@basic@flip.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/bat-dg2-9/igt@kms_busy@basic@flip.html * igt@kms_busy@basic@modeset: - {bat-adlp-6}: [DMESG-WARN][18] ([i915#3576]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11436/bat-adlp-6/igt@kms_busy@basic@modeset.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/bat-adlp-6/igt@kms_busy@basic@modeset.html * igt@kms_flip@basic-flip-vs-modeset@a-edp1: - fi-tgl-u2: [DMESG-WARN][20] ([i915#402]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11436/fi-tgl-u2/igt@kms_flip@basic-flip-vs-modeset@a-edp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/fi-tgl-u2/igt@kms_flip@basic-flip-vs-modeset@a-edp1.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155 [i915#1208]: https://gitlab.freedesktop.org/drm/intel/issues/1208 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576 [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213 [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269 [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873 [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957 [i915#5068]: https://gitlab.freedesktop.org/drm/intel/issues/5068 [i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127 [i915#5193]: https://gitlab.freedesktop.org/drm/intel/issues/5193 [i915#5270]: https://gitlab.freedesktop.org/drm/intel/issues/5270 [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274 [i915#5275]: https://gitlab.freedesktop.org/drm/intel/issues/5275 [i915#5291]: https://gitlab.freedesktop.org/drm/intel/issues/5291 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#5482]: https://gitlab.freedesktop.org/drm/intel/issues/5482 Build changes ------------- * Linux: CI_DRM_11436 -> Patchwork_22750 CI-20190529: 20190529 CI_DRM_11436: 76c1bd460d28ba331f0596c92c2201335e254ca2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6403: bc3f6833a12221a46659535dac06ebb312490eb4 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22750: 2d13341ec24639e8a876d18a8b668eabd1bc212a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2d13341ec246 drm/atomic-helpers: remove legacy_cursor_update hacks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22750/index.html [-- Attachment #2: Type: text/html, Size: 8303 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter @ 2022-04-01 8:39 ` Maxime Ripard -1 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2022-04-01 8:39 UTC (permalink / raw) To: Daniel Vetter Cc: Intel Graphics Development, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Michel Dänzer On Thu, Mar 31, 2022 at 05:20:21PM +0200, Daniel Vetter wrote: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Maxime ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-01 8:39 ` Maxime Ripard 0 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2022-04-01 8:39 UTC (permalink / raw) To: Daniel Vetter Cc: Intel Graphics Development, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, mikita.lipski, harry.wentland, Michel Dänzer On Thu, Mar 31, 2022 at 05:20:21PM +0200, Daniel Vetter wrote: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Maxime ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter @ 2022-04-06 21:57 ` Rob Clark -1 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2022-04-06 21:57 UTC (permalink / raw) To: Daniel Vetter Cc: Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Mikita Lipski, Intel Graphics Development On Thu, Mar 31, 2022 at 8:20 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > 3 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index 9603193d2fa1..a2899af82b4a 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index d2abe0e430bf..6ca5a6e7703b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b3cfabebe5d6 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-06 21:57 ` Rob Clark 0 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2022-04-06 21:57 UTC (permalink / raw) To: Daniel Vetter Cc: Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Mikita Lipski, Harry Wentland, Intel Graphics Development On Thu, Mar 31, 2022 at 8:20 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > 3 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index 9603193d2fa1..a2899af82b4a 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index d2abe0e430bf..6ca5a6e7703b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b3cfabebe5d6 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter @ 2022-04-07 1:27 ` Jessica Zhang -1 siblings, 0 replies; 80+ messages in thread From: Jessica Zhang @ 2022-04-07 1:27 UTC (permalink / raw) To: Rob Clark Cc: Daniel Vetter, Michel Dänzer, DRI Development, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas On 3/31/2022 8:20 AM, Daniel Vetter wrote: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> Hey Rob, I saw your tested-by and reviewed-by tags on Patchwork. Just curious, what device did you test on? I'm hitting several instances of this error when doing a start/stop ui on Lazor Chromebook with this patch: [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 e5912cd286513b064a82a38938b3fdef86b079aa [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen (rev4) (DT) [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 [ 3092.647379] sp : ffffffc00c1e3760 [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: 0000000000000425 [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: ffffffdf8ae3b6f0 [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: ffffff809b82da00 [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: 0000000000001000 [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: 000000000000003b [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000003 [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : 0000000000000040 [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : 0000000000000004 [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : 0000000000000000 [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : ffffff809a1eb300 [ 3092.724424] Call trace: [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 [ 3092.741627] commit_tail+0x7c/0xfc [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c [ 3092.749998] drm_atomic_commit+0x60/0x74 [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 [ 3092.759449] __setplane_atomic+0x11c/0x120 [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 [ 3092.781770] drm_ioctl+0x320/0x370 [ 3092.785289] drm_compat_ioctl+0x40/0xdc [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 [ 3092.794030] invoke_syscall+0x80/0x114 [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 [ 3092.802765] do_el0_svc_compat+0x2c/0x54 [ 3092.806811] el0_svc_compat+0x4c/0xe4 [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 [ 3092.814914] el0t_32_sync+0x174/0x178 [ 3092.818701] irq event stamp: 55940 [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] exit_to_kernel_mode+0x10c/0x11c [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] el1_dbg+0x28/0x70 [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] __do_softirq+0x1e8/0x480 [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] __irq_exit_rcu+0xdc/0x140 [ 3092.857022] ---[ end trace 0000000000000000 ]--- Thanks, Jessica Zhang > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > 3 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index 9603193d2fa1..a2899af82b4a 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index d2abe0e430bf..6ca5a6e7703b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b3cfabebe5d6 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-07 1:27 ` Jessica Zhang 0 siblings, 0 replies; 80+ messages in thread From: Jessica Zhang @ 2022-04-07 1:27 UTC (permalink / raw) To: Rob Clark Cc: Daniel Vetter, Michel Dänzer, DRI Development, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas On 3/31/2022 8:20 AM, Daniel Vetter wrote: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> Hey Rob, I saw your tested-by and reviewed-by tags on Patchwork. Just curious, what device did you test on? I'm hitting several instances of this error when doing a start/stop ui on Lazor Chromebook with this patch: [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 e5912cd286513b064a82a38938b3fdef86b079aa [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen (rev4) (DT) [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 [ 3092.647379] sp : ffffffc00c1e3760 [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: 0000000000000425 [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: ffffffdf8ae3b6f0 [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: ffffff809b82da00 [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: 0000000000001000 [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: 000000000000003b [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000003 [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : 0000000000000040 [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : 0000000000000004 [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : 0000000000000000 [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : ffffff809a1eb300 [ 3092.724424] Call trace: [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 [ 3092.741627] commit_tail+0x7c/0xfc [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c [ 3092.749998] drm_atomic_commit+0x60/0x74 [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 [ 3092.759449] __setplane_atomic+0x11c/0x120 [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 [ 3092.781770] drm_ioctl+0x320/0x370 [ 3092.785289] drm_compat_ioctl+0x40/0xdc [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 [ 3092.794030] invoke_syscall+0x80/0x114 [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 [ 3092.802765] do_el0_svc_compat+0x2c/0x54 [ 3092.806811] el0_svc_compat+0x4c/0xe4 [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 [ 3092.814914] el0t_32_sync+0x174/0x178 [ 3092.818701] irq event stamp: 55940 [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] exit_to_kernel_mode+0x10c/0x11c [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] el1_dbg+0x28/0x70 [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] __do_softirq+0x1e8/0x480 [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] __irq_exit_rcu+0xdc/0x140 [ 3092.857022] ---[ end trace 0000000000000000 ]--- Thanks, Jessica Zhang > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > 3 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index 9603193d2fa1..a2899af82b4a 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index d2abe0e430bf..6ca5a6e7703b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b3cfabebe5d6 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-07 1:27 ` [Intel-gfx] " Jessica Zhang @ 2022-04-07 9:33 ` Daniel Vetter -1 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-07 9:33 UTC (permalink / raw) To: Jessica Zhang Cc: Daniel Vetter, Michel Dänzer, DRI Development, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas On Wed, Apr 06, 2022 at 06:27:00PM -0700, Jessica Zhang wrote: > > > On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Hey Rob, > > I saw your tested-by and reviewed-by tags on Patchwork. Just curious, what > device did you test on? > > I'm hitting several instances of this error when doing a start/stop ui on > Lazor Chromebook with this patch: > I'm not familiar with arm splats, what goes boom here? I looked a bit at the code, and I have no idea how I manged to make things explode in there with my patch ... -Daniel > [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > e5912cd286513b064a82a38938b3fdef86b079aa > [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > (rev4) (DT) > [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > [ 3092.647379] sp : ffffffc00c1e3760 > [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > 0000000000000425 > [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > ffffffdf8ae3b6f0 > [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > ffffff809b82da00 > [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > 0000000000001000 > [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > 000000000000003b > [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > 0000000000000003 > [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > 0000000000000040 > [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > 0000000000000004 > [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > 0000000000000000 > [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > ffffff809a1eb300 > [ 3092.724424] Call trace: > [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > [ 3092.741627] commit_tail+0x7c/0xfc > [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > [ 3092.749998] drm_atomic_commit+0x60/0x74 > [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > [ 3092.759449] __setplane_atomic+0x11c/0x120 > [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > [ 3092.781770] drm_ioctl+0x320/0x370 > [ 3092.785289] drm_compat_ioctl+0x40/0xdc > [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > [ 3092.794030] invoke_syscall+0x80/0x114 > [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > [ 3092.806811] el0_svc_compat+0x4c/0xe4 > [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > [ 3092.814914] el0t_32_sync+0x174/0x178 > [ 3092.818701] irq event stamp: 55940 > [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > exit_to_kernel_mode+0x10c/0x11c > [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > el1_dbg+0x28/0x70 > [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > __do_softirq+0x1e8/0x480 > [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > __irq_exit_rcu+0xdc/0x140 > [ 3092.857022] ---[ end trace 0000000000000000 ]--- > > > > > Thanks, > > Jessica Zhang > > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > 3 files changed, 16 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index 9603193d2fa1..a2899af82b4a 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index d2abe0e430bf..6ca5a6e7703b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b3cfabebe5d6 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > > 2.34.1 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-07 9:33 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-07 9:33 UTC (permalink / raw) To: Jessica Zhang Cc: Daniel Vetter, Michel Dänzer, DRI Development, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas On Wed, Apr 06, 2022 at 06:27:00PM -0700, Jessica Zhang wrote: > > > On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Hey Rob, > > I saw your tested-by and reviewed-by tags on Patchwork. Just curious, what > device did you test on? > > I'm hitting several instances of this error when doing a start/stop ui on > Lazor Chromebook with this patch: > I'm not familiar with arm splats, what goes boom here? I looked a bit at the code, and I have no idea how I manged to make things explode in there with my patch ... -Daniel > [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > e5912cd286513b064a82a38938b3fdef86b079aa > [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > (rev4) (DT) > [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > [ 3092.647379] sp : ffffffc00c1e3760 > [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > 0000000000000425 > [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > ffffffdf8ae3b6f0 > [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > ffffff809b82da00 > [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > 0000000000001000 > [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > 000000000000003b > [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > 0000000000000003 > [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > 0000000000000040 > [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > 0000000000000004 > [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > 0000000000000000 > [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > ffffff809a1eb300 > [ 3092.724424] Call trace: > [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > [ 3092.741627] commit_tail+0x7c/0xfc > [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > [ 3092.749998] drm_atomic_commit+0x60/0x74 > [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > [ 3092.759449] __setplane_atomic+0x11c/0x120 > [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > [ 3092.781770] drm_ioctl+0x320/0x370 > [ 3092.785289] drm_compat_ioctl+0x40/0xdc > [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > [ 3092.794030] invoke_syscall+0x80/0x114 > [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > [ 3092.806811] el0_svc_compat+0x4c/0xe4 > [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > [ 3092.814914] el0t_32_sync+0x174/0x178 > [ 3092.818701] irq event stamp: 55940 > [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > exit_to_kernel_mode+0x10c/0x11c > [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > el1_dbg+0x28/0x70 > [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > __do_softirq+0x1e8/0x480 > [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > __irq_exit_rcu+0xdc/0x140 > [ 3092.857022] ---[ end trace 0000000000000000 ]--- > > > > > Thanks, > > Jessica Zhang > > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > 3 files changed, 16 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index 9603193d2fa1..a2899af82b4a 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index d2abe0e430bf..6ca5a6e7703b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b3cfabebe5d6 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > > 2.34.1 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-07 1:27 ` [Intel-gfx] " Jessica Zhang @ 2022-04-07 22:51 ` Rob Clark -1 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2022-04-07 22:51 UTC (permalink / raw) To: Jessica Zhang Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Mikita Lipski, Intel Graphics Development, Kazlauskas, Nicholas On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: > > > > On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Hey Rob, > > I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > what device did you test on? I was testing on strongbad.. v5.18-rc1 + patches (notably, revert 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") I think the display setup shouldn't be significantly different than limozeen (ie. it's an eDP panel). But I didn't do much start/stop ui.. I was mostly looking to make sure cursor movements weren't causing fps drops ;-) BR, -R > I'm hitting several instances of this error when doing a start/stop ui > on Lazor Chromebook with this patch: > > [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > e5912cd286513b064a82a38938b3fdef86b079aa > [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > (rev4) (DT) > [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > [ 3092.647379] sp : ffffffc00c1e3760 > [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > 0000000000000425 > [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > ffffffdf8ae3b6f0 > [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > ffffff809b82da00 > [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > 0000000000001000 > [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > 000000000000003b > [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > 0000000000000003 > [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > 0000000000000040 > [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > 0000000000000004 > [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > 0000000000000000 > [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > ffffff809a1eb300 > [ 3092.724424] Call trace: > [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > [ 3092.741627] commit_tail+0x7c/0xfc > [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > [ 3092.749998] drm_atomic_commit+0x60/0x74 > [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > [ 3092.759449] __setplane_atomic+0x11c/0x120 > [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > [ 3092.781770] drm_ioctl+0x320/0x370 > [ 3092.785289] drm_compat_ioctl+0x40/0xdc > [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > [ 3092.794030] invoke_syscall+0x80/0x114 > [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > [ 3092.806811] el0_svc_compat+0x4c/0xe4 > [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > [ 3092.814914] el0t_32_sync+0x174/0x178 > [ 3092.818701] irq event stamp: 55940 > [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > exit_to_kernel_mode+0x10c/0x11c > [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > el1_dbg+0x28/0x70 > [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > __do_softirq+0x1e8/0x480 > [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > __irq_exit_rcu+0xdc/0x140 > [ 3092.857022] ---[ end trace 0000000000000000 ]--- > > > > > Thanks, > > Jessica Zhang > > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > 3 files changed, 16 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index 9603193d2fa1..a2899af82b4a 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index d2abe0e430bf..6ca5a6e7703b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b3cfabebe5d6 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > > 2.34.1 > > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-07 22:51 ` Rob Clark 0 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2022-04-07 22:51 UTC (permalink / raw) To: Jessica Zhang Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Mikita Lipski, Intel Graphics Development, Kazlauskas, Nicholas On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: > > > > On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Hey Rob, > > I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > what device did you test on? I was testing on strongbad.. v5.18-rc1 + patches (notably, revert 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") I think the display setup shouldn't be significantly different than limozeen (ie. it's an eDP panel). But I didn't do much start/stop ui.. I was mostly looking to make sure cursor movements weren't causing fps drops ;-) BR, -R > I'm hitting several instances of this error when doing a start/stop ui > on Lazor Chromebook with this patch: > > [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > e5912cd286513b064a82a38938b3fdef86b079aa > [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > (rev4) (DT) > [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > [ 3092.647379] sp : ffffffc00c1e3760 > [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > 0000000000000425 > [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > ffffffdf8ae3b6f0 > [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > ffffff809b82da00 > [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > 0000000000001000 > [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > 000000000000003b > [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > 0000000000000003 > [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > 0000000000000040 > [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > 0000000000000004 > [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > 0000000000000000 > [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > ffffff809a1eb300 > [ 3092.724424] Call trace: > [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > [ 3092.741627] commit_tail+0x7c/0xfc > [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > [ 3092.749998] drm_atomic_commit+0x60/0x74 > [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > [ 3092.759449] __setplane_atomic+0x11c/0x120 > [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > [ 3092.781770] drm_ioctl+0x320/0x370 > [ 3092.785289] drm_compat_ioctl+0x40/0xdc > [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > [ 3092.794030] invoke_syscall+0x80/0x114 > [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > [ 3092.806811] el0_svc_compat+0x4c/0xe4 > [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > [ 3092.814914] el0t_32_sync+0x174/0x178 > [ 3092.818701] irq event stamp: 55940 > [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > exit_to_kernel_mode+0x10c/0x11c > [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > el1_dbg+0x28/0x70 > [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > __do_softirq+0x1e8/0x480 > [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > __irq_exit_rcu+0xdc/0x140 > [ 3092.857022] ---[ end trace 0000000000000000 ]--- > > > > > Thanks, > > Jessica Zhang > > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > 3 files changed, 16 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index 9603193d2fa1..a2899af82b4a 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index d2abe0e430bf..6ca5a6e7703b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b3cfabebe5d6 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > > 2.34.1 > > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-07 22:51 ` [Intel-gfx] " Rob Clark @ 2022-04-07 22:59 ` Abhinav Kumar -1 siblings, 0 replies; 80+ messages in thread From: Abhinav Kumar @ 2022-04-07 22:59 UTC (permalink / raw) To: Rob Clark, Jessica Zhang Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Mikita Lipski, Intel Graphics Development Hi Rob and Daniel On 4/7/2022 3:51 PM, Rob Clark wrote: > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: >> >> >> >> On 3/31/2022 8:20 AM, Daniel Vetter wrote: >>> The stuff never really worked, and leads to lots of fun because it >>> out-of-order frees atomic states. Which upsets KASAN, among other >>> things. >>> >>> For async updates we now have a more solid solution with the >>> ->atomic_async_check and ->atomic_async_commit hooks. Support for that >>> for msm and vc4 landed. nouveau and i915 have their own commit >>> routines, doing something similar. >>> >>> For everyone else it's probably better to remove the use-after-free >>> bug, and encourage folks to use the async support instead. The >>> affected drivers which register a legacy cursor plane and don't either >>> use the new async stuff or their own commit routine are: amdgpu, >>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. >>> >>> Inspired by an amdgpu bug report. >>> >>> v2: Drop RFC, I think with amdgpu converted over to use >>> atomic_async_check/commit done in >>> >>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 >>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>> Date: Wed Dec 5 14:59:07 2018 -0500 >>> >>> drm/amd/display: Add fast path for cursor plane updates >>> >>> we don't have any driver anymore where we have userspace expecting >>> solid legacy cursor support _and_ they are using the atomic helpers in >>> their fully glory. So we can retire this. >>> >>> v3: Paper over msm and i915 regression. The complete_all is the only >>> thing missing afaict. >>> >>> v4: Fixup i915 fixup ... >>> >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>> References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>> Cc: Maxime Ripard <maxime@cerno.tech> >>> Tested-by: Maxime Ripard <maxime@cerno.tech> >>> Cc: mikita.lipski@amd.com >>> Cc: Michel Dänzer <michel@daenzer.net> >>> Cc: harry.wentland@amd.com >>> Cc: Rob Clark <robdclark@gmail.com> >> >> Hey Rob, >> >> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, >> what device did you test on? > > I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > I think the display setup shouldn't be significantly different than > limozeen (ie. it's an eDP panel). But I didn't do much start/stop > ui.. I was mostly looking to make sure cursor movements weren't > causing fps drops ;-) > > BR, > -R start ui/ stop ui is a basic operation for us to use IGT on msm-next. So we cannot let that break. I think we need to check whats causing this splat. Can we hold back this change till then? Thanks Abhinav > >> I'm hitting several instances of this error when doing a start/stop ui >> on Lazor Chromebook with this patch: >> >> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W >> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 >> e5912cd286513b064a82a38938b3fdef86b079aa >> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen >> (rev4) (DT) >> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS >> BTYPE=--) >> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 >> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 >> [ 3092.647379] sp : ffffffc00c1e3760 >> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: >> 0000000000000425 >> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: >> ffffffdf8ae3b6f0 >> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: >> ffffff809b82da00 >> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: >> 0000000000001000 >> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: >> 000000000000003b >> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: >> 0000000000000003 >> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : >> 0000000000000040 >> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : >> 0000000000000004 >> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : >> 0000000000000000 >> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : >> ffffff809a1eb300 >> [ 3092.724424] Call trace: >> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 >> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 >> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 >> [ 3092.741627] commit_tail+0x7c/0xfc >> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c >> [ 3092.749998] drm_atomic_commit+0x60/0x74 >> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 >> [ 3092.759449] __setplane_atomic+0x11c/0x120 >> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c >> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 >> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c >> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 >> [ 3092.781770] drm_ioctl+0x320/0x370 >> [ 3092.785289] drm_compat_ioctl+0x40/0xdc >> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 >> [ 3092.794030] invoke_syscall+0x80/0x114 >> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 >> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 >> [ 3092.806811] el0_svc_compat+0x4c/0xe4 >> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 >> [ 3092.814914] el0t_32_sync+0x174/0x178 >> [ 3092.818701] irq event stamp: 55940 >> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] >> exit_to_kernel_mode+0x10c/0x11c >> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] >> el1_dbg+0x28/0x70 >> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] >> __do_softirq+0x1e8/0x480 >> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] >> __irq_exit_rcu+0xdc/0x140 >> [ 3092.857022] ---[ end trace 0000000000000000 ]--- >> >> >> >> >> Thanks, >> >> Jessica Zhang >> >>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> >>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>> --- >>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- >>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ >>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ >>> 3 files changed, 16 insertions(+), 13 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c >>> index 9603193d2fa1..a2899af82b4a 100644 >>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, >>> int i, ret; >>> unsigned int crtc_mask = 0; >>> >>> - /* >>> - * Legacy cursor ioctls are completely unsynced, and userspace >>> - * relies on that (by doing tons of cursor updates). >>> - */ >>> - if (old_state->legacy_cursor_update) >>> - return; >>> - >>> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { >>> if (!new_crtc_state->active) >>> continue; >>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, >>> continue; >>> } >>> >>> - /* Legacy cursor updates are fully unsynced. */ >>> - if (state->legacy_cursor_update) { >>> - complete_all(&commit->flip_done); >>> - continue; >>> - } >>> - >>> if (!new_crtc_state->event) { >>> commit->event = kzalloc(sizeof(*commit->event), >>> GFP_KERNEL); >>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c >>> index d2abe0e430bf..6ca5a6e7703b 100644 >>> --- a/drivers/gpu/drm/i915/display/intel_display.c >>> +++ b/drivers/gpu/drm/i915/display/intel_display.c >>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, >>> intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); >>> return ret; >>> } >>> + >>> + /* >>> + * FIXME: Cut over to (async) commit helpers instead of hand-rolling >>> + * everything. >>> + */ >>> + if (state->base.legacy_cursor_update) { >>> + struct intel_crtc_state *new_crtc_state; >>> + struct intel_crtc *crtc; >>> + int i; >>> + >>> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) >>> + complete_all(&new_crtc_state->uapi.commit->flip_done); >>> + } >>> + >>> intel_shared_dpll_swap_state(state); >>> intel_atomic_track_fbs(state); >>> >>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c >>> index 1686fbb611fd..b3cfabebe5d6 100644 >>> --- a/drivers/gpu/drm/msm/msm_atomic.c >>> +++ b/drivers/gpu/drm/msm/msm_atomic.c >>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) >>> /* async updates are limited to single-crtc updates: */ >>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); >>> >>> + complete_all(&async_crtc->state->commit->flip_done); >>> + >>> /* >>> * Start timer if we don't already have an update pending >>> * on this crtc: >>> -- >>> 2.34.1 >>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-07 22:59 ` Abhinav Kumar 0 siblings, 0 replies; 80+ messages in thread From: Abhinav Kumar @ 2022-04-07 22:59 UTC (permalink / raw) To: Rob Clark, Jessica Zhang Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Mikita Lipski, Intel Graphics Development Hi Rob and Daniel On 4/7/2022 3:51 PM, Rob Clark wrote: > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: >> >> >> >> On 3/31/2022 8:20 AM, Daniel Vetter wrote: >>> The stuff never really worked, and leads to lots of fun because it >>> out-of-order frees atomic states. Which upsets KASAN, among other >>> things. >>> >>> For async updates we now have a more solid solution with the >>> ->atomic_async_check and ->atomic_async_commit hooks. Support for that >>> for msm and vc4 landed. nouveau and i915 have their own commit >>> routines, doing something similar. >>> >>> For everyone else it's probably better to remove the use-after-free >>> bug, and encourage folks to use the async support instead. The >>> affected drivers which register a legacy cursor plane and don't either >>> use the new async stuff or their own commit routine are: amdgpu, >>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. >>> >>> Inspired by an amdgpu bug report. >>> >>> v2: Drop RFC, I think with amdgpu converted over to use >>> atomic_async_check/commit done in >>> >>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 >>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>> Date: Wed Dec 5 14:59:07 2018 -0500 >>> >>> drm/amd/display: Add fast path for cursor plane updates >>> >>> we don't have any driver anymore where we have userspace expecting >>> solid legacy cursor support _and_ they are using the atomic helpers in >>> their fully glory. So we can retire this. >>> >>> v3: Paper over msm and i915 regression. The complete_all is the only >>> thing missing afaict. >>> >>> v4: Fixup i915 fixup ... >>> >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>> References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>> Cc: Maxime Ripard <maxime@cerno.tech> >>> Tested-by: Maxime Ripard <maxime@cerno.tech> >>> Cc: mikita.lipski@amd.com >>> Cc: Michel Dänzer <michel@daenzer.net> >>> Cc: harry.wentland@amd.com >>> Cc: Rob Clark <robdclark@gmail.com> >> >> Hey Rob, >> >> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, >> what device did you test on? > > I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > I think the display setup shouldn't be significantly different than > limozeen (ie. it's an eDP panel). But I didn't do much start/stop > ui.. I was mostly looking to make sure cursor movements weren't > causing fps drops ;-) > > BR, > -R start ui/ stop ui is a basic operation for us to use IGT on msm-next. So we cannot let that break. I think we need to check whats causing this splat. Can we hold back this change till then? Thanks Abhinav > >> I'm hitting several instances of this error when doing a start/stop ui >> on Lazor Chromebook with this patch: >> >> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W >> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 >> e5912cd286513b064a82a38938b3fdef86b079aa >> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen >> (rev4) (DT) >> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS >> BTYPE=--) >> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 >> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 >> [ 3092.647379] sp : ffffffc00c1e3760 >> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: >> 0000000000000425 >> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: >> ffffffdf8ae3b6f0 >> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: >> ffffff809b82da00 >> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: >> 0000000000001000 >> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: >> 000000000000003b >> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: >> 0000000000000003 >> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : >> 0000000000000040 >> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : >> 0000000000000004 >> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : >> 0000000000000000 >> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : >> ffffff809a1eb300 >> [ 3092.724424] Call trace: >> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 >> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 >> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 >> [ 3092.741627] commit_tail+0x7c/0xfc >> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c >> [ 3092.749998] drm_atomic_commit+0x60/0x74 >> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 >> [ 3092.759449] __setplane_atomic+0x11c/0x120 >> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c >> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 >> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c >> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 >> [ 3092.781770] drm_ioctl+0x320/0x370 >> [ 3092.785289] drm_compat_ioctl+0x40/0xdc >> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 >> [ 3092.794030] invoke_syscall+0x80/0x114 >> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 >> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 >> [ 3092.806811] el0_svc_compat+0x4c/0xe4 >> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 >> [ 3092.814914] el0t_32_sync+0x174/0x178 >> [ 3092.818701] irq event stamp: 55940 >> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] >> exit_to_kernel_mode+0x10c/0x11c >> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] >> el1_dbg+0x28/0x70 >> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] >> __do_softirq+0x1e8/0x480 >> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] >> __irq_exit_rcu+0xdc/0x140 >> [ 3092.857022] ---[ end trace 0000000000000000 ]--- >> >> >> >> >> Thanks, >> >> Jessica Zhang >> >>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> >>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>> --- >>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- >>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ >>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ >>> 3 files changed, 16 insertions(+), 13 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c >>> index 9603193d2fa1..a2899af82b4a 100644 >>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, >>> int i, ret; >>> unsigned int crtc_mask = 0; >>> >>> - /* >>> - * Legacy cursor ioctls are completely unsynced, and userspace >>> - * relies on that (by doing tons of cursor updates). >>> - */ >>> - if (old_state->legacy_cursor_update) >>> - return; >>> - >>> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { >>> if (!new_crtc_state->active) >>> continue; >>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, >>> continue; >>> } >>> >>> - /* Legacy cursor updates are fully unsynced. */ >>> - if (state->legacy_cursor_update) { >>> - complete_all(&commit->flip_done); >>> - continue; >>> - } >>> - >>> if (!new_crtc_state->event) { >>> commit->event = kzalloc(sizeof(*commit->event), >>> GFP_KERNEL); >>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c >>> index d2abe0e430bf..6ca5a6e7703b 100644 >>> --- a/drivers/gpu/drm/i915/display/intel_display.c >>> +++ b/drivers/gpu/drm/i915/display/intel_display.c >>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, >>> intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); >>> return ret; >>> } >>> + >>> + /* >>> + * FIXME: Cut over to (async) commit helpers instead of hand-rolling >>> + * everything. >>> + */ >>> + if (state->base.legacy_cursor_update) { >>> + struct intel_crtc_state *new_crtc_state; >>> + struct intel_crtc *crtc; >>> + int i; >>> + >>> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) >>> + complete_all(&new_crtc_state->uapi.commit->flip_done); >>> + } >>> + >>> intel_shared_dpll_swap_state(state); >>> intel_atomic_track_fbs(state); >>> >>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c >>> index 1686fbb611fd..b3cfabebe5d6 100644 >>> --- a/drivers/gpu/drm/msm/msm_atomic.c >>> +++ b/drivers/gpu/drm/msm/msm_atomic.c >>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) >>> /* async updates are limited to single-crtc updates: */ >>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); >>> >>> + complete_all(&async_crtc->state->commit->flip_done); >>> + >>> /* >>> * Start timer if we don't already have an update pending >>> * on this crtc: >>> -- >>> 2.34.1 >>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-07 22:59 ` [Intel-gfx] " Abhinav Kumar @ 2022-04-07 23:12 ` Rob Clark -1 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2022-04-07 23:12 UTC (permalink / raw) To: Abhinav Kumar Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > Hi Rob and Daniel > > On 4/7/2022 3:51 PM, Rob Clark wrote: > > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: > >> > >> > >> > >> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > >>> The stuff never really worked, and leads to lots of fun because it > >>> out-of-order frees atomic states. Which upsets KASAN, among other > >>> things. > >>> > >>> For async updates we now have a more solid solution with the > >>> ->atomic_async_check and ->atomic_async_commit hooks. Support for that > >>> for msm and vc4 landed. nouveau and i915 have their own commit > >>> routines, doing something similar. > >>> > >>> For everyone else it's probably better to remove the use-after-free > >>> bug, and encourage folks to use the async support instead. The > >>> affected drivers which register a legacy cursor plane and don't either > >>> use the new async stuff or their own commit routine are: amdgpu, > >>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > >>> > >>> Inspired by an amdgpu bug report. > >>> > >>> v2: Drop RFC, I think with amdgpu converted over to use > >>> atomic_async_check/commit done in > >>> > >>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > >>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > >>> Date: Wed Dec 5 14:59:07 2018 -0500 > >>> > >>> drm/amd/display: Add fast path for cursor plane updates > >>> > >>> we don't have any driver anymore where we have userspace expecting > >>> solid legacy cursor support _and_ they are using the atomic helpers in > >>> their fully glory. So we can retire this. > >>> > >>> v3: Paper over msm and i915 regression. The complete_all is the only > >>> thing missing afaict. > >>> > >>> v4: Fixup i915 fixup ... > >>> > >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>> References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>> Cc: Maxime Ripard <maxime@cerno.tech> > >>> Tested-by: Maxime Ripard <maxime@cerno.tech> > >>> Cc: mikita.lipski@amd.com > >>> Cc: Michel Dänzer <michel@daenzer.net> > >>> Cc: harry.wentland@amd.com > >>> Cc: Rob Clark <robdclark@gmail.com> > >> > >> Hey Rob, > >> > >> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > >> what device did you test on? > > > > I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > > > I think the display setup shouldn't be significantly different than > > limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > ui.. I was mostly looking to make sure cursor movements weren't > > causing fps drops ;-) > > > > BR, > > -R > > start ui/ stop ui is a basic operation for us to use IGT on msm-next. > So we cannot let that break. > > I think we need to check whats causing this splat. > > Can we hold back this change till then? Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a loop of stop ui / start ui and hasn't triggered a splat yet. Otherwise maybe you can addr2line to figure out where it crashed? BR, -R > Thanks > > Abhinav > > > >> I'm hitting several instances of this error when doing a start/stop ui > >> on Lazor Chromebook with this patch: > >> > >> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > >> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > >> e5912cd286513b064a82a38938b3fdef86b079aa > >> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > >> (rev4) (DT) > >> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > >> BTYPE=--) > >> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > >> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > >> [ 3092.647379] sp : ffffffc00c1e3760 > >> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > >> 0000000000000425 > >> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > >> ffffffdf8ae3b6f0 > >> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > >> ffffff809b82da00 > >> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > >> 0000000000001000 > >> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > >> 000000000000003b > >> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > >> 0000000000000003 > >> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > >> 0000000000000040 > >> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > >> 0000000000000004 > >> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > >> 0000000000000000 > >> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > >> ffffff809a1eb300 > >> [ 3092.724424] Call trace: > >> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > >> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > >> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > >> [ 3092.741627] commit_tail+0x7c/0xfc > >> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > >> [ 3092.749998] drm_atomic_commit+0x60/0x74 > >> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > >> [ 3092.759449] __setplane_atomic+0x11c/0x120 > >> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > >> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > >> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > >> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > >> [ 3092.781770] drm_ioctl+0x320/0x370 > >> [ 3092.785289] drm_compat_ioctl+0x40/0xdc > >> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > >> [ 3092.794030] invoke_syscall+0x80/0x114 > >> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > >> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > >> [ 3092.806811] el0_svc_compat+0x4c/0xe4 > >> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > >> [ 3092.814914] el0t_32_sync+0x174/0x178 > >> [ 3092.818701] irq event stamp: 55940 > >> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > >> exit_to_kernel_mode+0x10c/0x11c > >> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > >> el1_dbg+0x28/0x70 > >> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > >> __do_softirq+0x1e8/0x480 > >> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > >> __irq_exit_rcu+0xdc/0x140 > >> [ 3092.857022] ---[ end trace 0000000000000000 ]--- > >> > >> > >> > >> > >> Thanks, > >> > >> Jessica Zhang > >> > >>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > >>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > >>> --- > >>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > >>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > >>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > >>> 3 files changed, 16 insertions(+), 13 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > >>> index 9603193d2fa1..a2899af82b4a 100644 > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c > >>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > >>> int i, ret; > >>> unsigned int crtc_mask = 0; > >>> > >>> - /* > >>> - * Legacy cursor ioctls are completely unsynced, and userspace > >>> - * relies on that (by doing tons of cursor updates). > >>> - */ > >>> - if (old_state->legacy_cursor_update) > >>> - return; > >>> - > >>> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > >>> if (!new_crtc_state->active) > >>> continue; > >>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > >>> continue; > >>> } > >>> > >>> - /* Legacy cursor updates are fully unsynced. */ > >>> - if (state->legacy_cursor_update) { > >>> - complete_all(&commit->flip_done); > >>> - continue; > >>> - } > >>> - > >>> if (!new_crtc_state->event) { > >>> commit->event = kzalloc(sizeof(*commit->event), > >>> GFP_KERNEL); > >>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > >>> index d2abe0e430bf..6ca5a6e7703b 100644 > >>> --- a/drivers/gpu/drm/i915/display/intel_display.c > >>> +++ b/drivers/gpu/drm/i915/display/intel_display.c > >>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > >>> intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > >>> return ret; > >>> } > >>> + > >>> + /* > >>> + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > >>> + * everything. > >>> + */ > >>> + if (state->base.legacy_cursor_update) { > >>> + struct intel_crtc_state *new_crtc_state; > >>> + struct intel_crtc *crtc; > >>> + int i; > >>> + > >>> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > >>> + complete_all(&new_crtc_state->uapi.commit->flip_done); > >>> + } > >>> + > >>> intel_shared_dpll_swap_state(state); > >>> intel_atomic_track_fbs(state); > >>> > >>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > >>> index 1686fbb611fd..b3cfabebe5d6 100644 > >>> --- a/drivers/gpu/drm/msm/msm_atomic.c > >>> +++ b/drivers/gpu/drm/msm/msm_atomic.c > >>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > >>> /* async updates are limited to single-crtc updates: */ > >>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > >>> > >>> + complete_all(&async_crtc->state->commit->flip_done); > >>> + > >>> /* > >>> * Start timer if we don't already have an update pending > >>> * on this crtc: > >>> -- > >>> 2.34.1 > >>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-07 23:12 ` Rob Clark 0 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2022-04-07 23:12 UTC (permalink / raw) To: Abhinav Kumar Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > Hi Rob and Daniel > > On 4/7/2022 3:51 PM, Rob Clark wrote: > > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: > >> > >> > >> > >> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > >>> The stuff never really worked, and leads to lots of fun because it > >>> out-of-order frees atomic states. Which upsets KASAN, among other > >>> things. > >>> > >>> For async updates we now have a more solid solution with the > >>> ->atomic_async_check and ->atomic_async_commit hooks. Support for that > >>> for msm and vc4 landed. nouveau and i915 have their own commit > >>> routines, doing something similar. > >>> > >>> For everyone else it's probably better to remove the use-after-free > >>> bug, and encourage folks to use the async support instead. The > >>> affected drivers which register a legacy cursor plane and don't either > >>> use the new async stuff or their own commit routine are: amdgpu, > >>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > >>> > >>> Inspired by an amdgpu bug report. > >>> > >>> v2: Drop RFC, I think with amdgpu converted over to use > >>> atomic_async_check/commit done in > >>> > >>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > >>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > >>> Date: Wed Dec 5 14:59:07 2018 -0500 > >>> > >>> drm/amd/display: Add fast path for cursor plane updates > >>> > >>> we don't have any driver anymore where we have userspace expecting > >>> solid legacy cursor support _and_ they are using the atomic helpers in > >>> their fully glory. So we can retire this. > >>> > >>> v3: Paper over msm and i915 regression. The complete_all is the only > >>> thing missing afaict. > >>> > >>> v4: Fixup i915 fixup ... > >>> > >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>> References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>> Cc: Maxime Ripard <maxime@cerno.tech> > >>> Tested-by: Maxime Ripard <maxime@cerno.tech> > >>> Cc: mikita.lipski@amd.com > >>> Cc: Michel Dänzer <michel@daenzer.net> > >>> Cc: harry.wentland@amd.com > >>> Cc: Rob Clark <robdclark@gmail.com> > >> > >> Hey Rob, > >> > >> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > >> what device did you test on? > > > > I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > > > I think the display setup shouldn't be significantly different than > > limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > ui.. I was mostly looking to make sure cursor movements weren't > > causing fps drops ;-) > > > > BR, > > -R > > start ui/ stop ui is a basic operation for us to use IGT on msm-next. > So we cannot let that break. > > I think we need to check whats causing this splat. > > Can we hold back this change till then? Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a loop of stop ui / start ui and hasn't triggered a splat yet. Otherwise maybe you can addr2line to figure out where it crashed? BR, -R > Thanks > > Abhinav > > > >> I'm hitting several instances of this error when doing a start/stop ui > >> on Lazor Chromebook with this patch: > >> > >> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > >> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > >> e5912cd286513b064a82a38938b3fdef86b079aa > >> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > >> (rev4) (DT) > >> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > >> BTYPE=--) > >> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > >> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > >> [ 3092.647379] sp : ffffffc00c1e3760 > >> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > >> 0000000000000425 > >> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > >> ffffffdf8ae3b6f0 > >> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > >> ffffff809b82da00 > >> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > >> 0000000000001000 > >> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > >> 000000000000003b > >> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > >> 0000000000000003 > >> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > >> 0000000000000040 > >> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > >> 0000000000000004 > >> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > >> 0000000000000000 > >> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > >> ffffff809a1eb300 > >> [ 3092.724424] Call trace: > >> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > >> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > >> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > >> [ 3092.741627] commit_tail+0x7c/0xfc > >> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > >> [ 3092.749998] drm_atomic_commit+0x60/0x74 > >> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > >> [ 3092.759449] __setplane_atomic+0x11c/0x120 > >> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > >> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > >> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > >> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > >> [ 3092.781770] drm_ioctl+0x320/0x370 > >> [ 3092.785289] drm_compat_ioctl+0x40/0xdc > >> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > >> [ 3092.794030] invoke_syscall+0x80/0x114 > >> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > >> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > >> [ 3092.806811] el0_svc_compat+0x4c/0xe4 > >> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > >> [ 3092.814914] el0t_32_sync+0x174/0x178 > >> [ 3092.818701] irq event stamp: 55940 > >> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > >> exit_to_kernel_mode+0x10c/0x11c > >> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > >> el1_dbg+0x28/0x70 > >> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > >> __do_softirq+0x1e8/0x480 > >> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > >> __irq_exit_rcu+0xdc/0x140 > >> [ 3092.857022] ---[ end trace 0000000000000000 ]--- > >> > >> > >> > >> > >> Thanks, > >> > >> Jessica Zhang > >> > >>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > >>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > >>> --- > >>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > >>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > >>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > >>> 3 files changed, 16 insertions(+), 13 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > >>> index 9603193d2fa1..a2899af82b4a 100644 > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c > >>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > >>> int i, ret; > >>> unsigned int crtc_mask = 0; > >>> > >>> - /* > >>> - * Legacy cursor ioctls are completely unsynced, and userspace > >>> - * relies on that (by doing tons of cursor updates). > >>> - */ > >>> - if (old_state->legacy_cursor_update) > >>> - return; > >>> - > >>> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > >>> if (!new_crtc_state->active) > >>> continue; > >>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > >>> continue; > >>> } > >>> > >>> - /* Legacy cursor updates are fully unsynced. */ > >>> - if (state->legacy_cursor_update) { > >>> - complete_all(&commit->flip_done); > >>> - continue; > >>> - } > >>> - > >>> if (!new_crtc_state->event) { > >>> commit->event = kzalloc(sizeof(*commit->event), > >>> GFP_KERNEL); > >>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > >>> index d2abe0e430bf..6ca5a6e7703b 100644 > >>> --- a/drivers/gpu/drm/i915/display/intel_display.c > >>> +++ b/drivers/gpu/drm/i915/display/intel_display.c > >>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > >>> intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > >>> return ret; > >>> } > >>> + > >>> + /* > >>> + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > >>> + * everything. > >>> + */ > >>> + if (state->base.legacy_cursor_update) { > >>> + struct intel_crtc_state *new_crtc_state; > >>> + struct intel_crtc *crtc; > >>> + int i; > >>> + > >>> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > >>> + complete_all(&new_crtc_state->uapi.commit->flip_done); > >>> + } > >>> + > >>> intel_shared_dpll_swap_state(state); > >>> intel_atomic_track_fbs(state); > >>> > >>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > >>> index 1686fbb611fd..b3cfabebe5d6 100644 > >>> --- a/drivers/gpu/drm/msm/msm_atomic.c > >>> +++ b/drivers/gpu/drm/msm/msm_atomic.c > >>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > >>> /* async updates are limited to single-crtc updates: */ > >>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > >>> > >>> + complete_all(&async_crtc->state->commit->flip_done); > >>> + > >>> /* > >>> * Start timer if we don't already have an update pending > >>> * on this crtc: > >>> -- > >>> 2.34.1 > >>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-07 23:12 ` [Intel-gfx] " Rob Clark @ 2022-04-09 4:04 ` Abhinav Kumar -1 siblings, 0 replies; 80+ messages in thread From: Abhinav Kumar @ 2022-04-09 4:04 UTC (permalink / raw) To: Rob Clark Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On 4/7/2022 4:12 PM, Rob Clark wrote: > On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: >> >> Hi Rob and Daniel >> >> On 4/7/2022 3:51 PM, Rob Clark wrote: >>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: >>>> >>>> >>>> >>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: >>>>> The stuff never really worked, and leads to lots of fun because it >>>>> out-of-order frees atomic states. Which upsets KASAN, among other >>>>> things. >>>>> >>>>> For async updates we now have a more solid solution with the >>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for that >>>>> for msm and vc4 landed. nouveau and i915 have their own commit >>>>> routines, doing something similar. >>>>> >>>>> For everyone else it's probably better to remove the use-after-free >>>>> bug, and encourage folks to use the async support instead. The >>>>> affected drivers which register a legacy cursor plane and don't either >>>>> use the new async stuff or their own commit routine are: amdgpu, >>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. >>>>> >>>>> Inspired by an amdgpu bug report. >>>>> >>>>> v2: Drop RFC, I think with amdgpu converted over to use >>>>> atomic_async_check/commit done in >>>>> >>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 >>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>>>> Date: Wed Dec 5 14:59:07 2018 -0500 >>>>> >>>>> drm/amd/display: Add fast path for cursor plane updates >>>>> >>>>> we don't have any driver anymore where we have userspace expecting >>>>> solid legacy cursor support _and_ they are using the atomic helpers in >>>>> their fully glory. So we can retire this. >>>>> >>>>> v3: Paper over msm and i915 regression. The complete_all is the only >>>>> thing missing afaict. >>>>> >>>>> v4: Fixup i915 fixup ... >>>>> >>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>> References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ >>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>> Cc: Maxime Ripard <maxime@cerno.tech> >>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> >>>>> Cc: mikita.lipski@amd.com >>>>> Cc: Michel Dänzer <michel@daenzer.net> >>>>> Cc: harry.wentland@amd.com >>>>> Cc: Rob Clark <robdclark@gmail.com> >>>> >>>> Hey Rob, >>>> >>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, >>>> what device did you test on? >>> >>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert >>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") >>> >>> I think the display setup shouldn't be significantly different than >>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop >>> ui.. I was mostly looking to make sure cursor movements weren't >>> causing fps drops ;-) >>> >>> BR, >>> -R >> >> start ui/ stop ui is a basic operation for us to use IGT on msm-next. >> So we cannot let that break. >> >> I think we need to check whats causing this splat. >> >> Can we hold back this change till then? > > Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > loop of stop ui / start ui and hasn't triggered a splat yet. > > Otherwise maybe you can addr2line to figure out where it crashed? > > BR, > -R So this is not a crash. Its a warning splat coming from https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 Looks like the complete_commit() which should signal the event has not happened before the next cursor commit. Somehow this change is affecting the flow to miss the event signaling that the event is done. We tried a couple of approaches but couldnt still fix the warning. Will continue to check further next week. > >> Thanks >> >> Abhinav >>> >>>> I'm hitting several instances of this error when doing a start/stop ui >>>> on Lazor Chromebook with this patch: >>>> >>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W >>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 >>>> e5912cd286513b064a82a38938b3fdef86b079aa >>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen >>>> (rev4) (DT) >>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS >>>> BTYPE=--) >>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 >>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 >>>> [ 3092.647379] sp : ffffffc00c1e3760 >>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: >>>> 0000000000000425 >>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: >>>> ffffffdf8ae3b6f0 >>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: >>>> ffffff809b82da00 >>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: >>>> 0000000000001000 >>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: >>>> 000000000000003b >>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: >>>> 0000000000000003 >>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : >>>> 0000000000000040 >>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : >>>> 0000000000000004 >>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : >>>> 0000000000000000 >>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : >>>> ffffff809a1eb300 >>>> [ 3092.724424] Call trace: >>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 >>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 >>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 >>>> [ 3092.741627] commit_tail+0x7c/0xfc >>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c >>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 >>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 >>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 >>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c >>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 >>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c >>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 >>>> [ 3092.781770] drm_ioctl+0x320/0x370 >>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc >>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 >>>> [ 3092.794030] invoke_syscall+0x80/0x114 >>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 >>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 >>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 >>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 >>>> [ 3092.814914] el0t_32_sync+0x174/0x178 >>>> [ 3092.818701] irq event stamp: 55940 >>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] >>>> exit_to_kernel_mode+0x10c/0x11c >>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] >>>> el1_dbg+0x28/0x70 >>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] >>>> __do_softirq+0x1e8/0x480 >>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] >>>> __irq_exit_rcu+0xdc/0x140 >>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jessica Zhang >>>> >>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> >>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>>>> --- >>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- >>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ >>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ >>>>> 3 files changed, 16 insertions(+), 13 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c >>>>> index 9603193d2fa1..a2899af82b4a 100644 >>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, >>>>> int i, ret; >>>>> unsigned int crtc_mask = 0; >>>>> >>>>> - /* >>>>> - * Legacy cursor ioctls are completely unsynced, and userspace >>>>> - * relies on that (by doing tons of cursor updates). >>>>> - */ >>>>> - if (old_state->legacy_cursor_update) >>>>> - return; >>>>> - >>>>> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { >>>>> if (!new_crtc_state->active) >>>>> continue; >>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, >>>>> continue; >>>>> } >>>>> >>>>> - /* Legacy cursor updates are fully unsynced. */ >>>>> - if (state->legacy_cursor_update) { >>>>> - complete_all(&commit->flip_done); >>>>> - continue; >>>>> - } >>>>> - >>>>> if (!new_crtc_state->event) { >>>>> commit->event = kzalloc(sizeof(*commit->event), >>>>> GFP_KERNEL); >>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c >>>>> index d2abe0e430bf..6ca5a6e7703b 100644 >>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c >>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c >>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, >>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); >>>>> return ret; >>>>> } >>>>> + >>>>> + /* >>>>> + * FIXME: Cut over to (async) commit helpers instead of hand-rolling >>>>> + * everything. >>>>> + */ >>>>> + if (state->base.legacy_cursor_update) { >>>>> + struct intel_crtc_state *new_crtc_state; >>>>> + struct intel_crtc *crtc; >>>>> + int i; >>>>> + >>>>> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) >>>>> + complete_all(&new_crtc_state->uapi.commit->flip_done); >>>>> + } >>>>> + >>>>> intel_shared_dpll_swap_state(state); >>>>> intel_atomic_track_fbs(state); >>>>> >>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c >>>>> index 1686fbb611fd..b3cfabebe5d6 100644 >>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c >>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c >>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) >>>>> /* async updates are limited to single-crtc updates: */ >>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); >>>>> >>>>> + complete_all(&async_crtc->state->commit->flip_done); >>>>> + >>>>> /* >>>>> * Start timer if we don't already have an update pending >>>>> * on this crtc: >>>>> -- >>>>> 2.34.1 >>>>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-09 4:04 ` Abhinav Kumar 0 siblings, 0 replies; 80+ messages in thread From: Abhinav Kumar @ 2022-04-09 4:04 UTC (permalink / raw) To: Rob Clark Cc: Rob Clark, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On 4/7/2022 4:12 PM, Rob Clark wrote: > On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: >> >> Hi Rob and Daniel >> >> On 4/7/2022 3:51 PM, Rob Clark wrote: >>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang <quic_jesszhan@quicinc.com> wrote: >>>> >>>> >>>> >>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: >>>>> The stuff never really worked, and leads to lots of fun because it >>>>> out-of-order frees atomic states. Which upsets KASAN, among other >>>>> things. >>>>> >>>>> For async updates we now have a more solid solution with the >>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for that >>>>> for msm and vc4 landed. nouveau and i915 have their own commit >>>>> routines, doing something similar. >>>>> >>>>> For everyone else it's probably better to remove the use-after-free >>>>> bug, and encourage folks to use the async support instead. The >>>>> affected drivers which register a legacy cursor plane and don't either >>>>> use the new async stuff or their own commit routine are: amdgpu, >>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. >>>>> >>>>> Inspired by an amdgpu bug report. >>>>> >>>>> v2: Drop RFC, I think with amdgpu converted over to use >>>>> atomic_async_check/commit done in >>>>> >>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 >>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>>>> Date: Wed Dec 5 14:59:07 2018 -0500 >>>>> >>>>> drm/amd/display: Add fast path for cursor plane updates >>>>> >>>>> we don't have any driver anymore where we have userspace expecting >>>>> solid legacy cursor support _and_ they are using the atomic helpers in >>>>> their fully glory. So we can retire this. >>>>> >>>>> v3: Paper over msm and i915 regression. The complete_all is the only >>>>> thing missing afaict. >>>>> >>>>> v4: Fixup i915 fixup ... >>>>> >>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>> References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ >>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>> Cc: Maxime Ripard <maxime@cerno.tech> >>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> >>>>> Cc: mikita.lipski@amd.com >>>>> Cc: Michel Dänzer <michel@daenzer.net> >>>>> Cc: harry.wentland@amd.com >>>>> Cc: Rob Clark <robdclark@gmail.com> >>>> >>>> Hey Rob, >>>> >>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, >>>> what device did you test on? >>> >>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert >>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") >>> >>> I think the display setup shouldn't be significantly different than >>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop >>> ui.. I was mostly looking to make sure cursor movements weren't >>> causing fps drops ;-) >>> >>> BR, >>> -R >> >> start ui/ stop ui is a basic operation for us to use IGT on msm-next. >> So we cannot let that break. >> >> I think we need to check whats causing this splat. >> >> Can we hold back this change till then? > > Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > loop of stop ui / start ui and hasn't triggered a splat yet. > > Otherwise maybe you can addr2line to figure out where it crashed? > > BR, > -R So this is not a crash. Its a warning splat coming from https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 Looks like the complete_commit() which should signal the event has not happened before the next cursor commit. Somehow this change is affecting the flow to miss the event signaling that the event is done. We tried a couple of approaches but couldnt still fix the warning. Will continue to check further next week. > >> Thanks >> >> Abhinav >>> >>>> I'm hitting several instances of this error when doing a start/stop ui >>>> on Lazor Chromebook with this patch: >>>> >>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W >>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 >>>> e5912cd286513b064a82a38938b3fdef86b079aa >>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen >>>> (rev4) (DT) >>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS >>>> BTYPE=--) >>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 >>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 >>>> [ 3092.647379] sp : ffffffc00c1e3760 >>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: >>>> 0000000000000425 >>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: >>>> ffffffdf8ae3b6f0 >>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: >>>> ffffff809b82da00 >>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: >>>> 0000000000001000 >>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: >>>> 000000000000003b >>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: >>>> 0000000000000003 >>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : >>>> 0000000000000040 >>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : >>>> 0000000000000004 >>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : >>>> 0000000000000000 >>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : >>>> ffffff809a1eb300 >>>> [ 3092.724424] Call trace: >>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 >>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 >>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 >>>> [ 3092.741627] commit_tail+0x7c/0xfc >>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c >>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 >>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 >>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 >>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c >>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 >>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c >>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 >>>> [ 3092.781770] drm_ioctl+0x320/0x370 >>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc >>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 >>>> [ 3092.794030] invoke_syscall+0x80/0x114 >>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 >>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 >>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 >>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 >>>> [ 3092.814914] el0t_32_sync+0x174/0x178 >>>> [ 3092.818701] irq event stamp: 55940 >>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] >>>> exit_to_kernel_mode+0x10c/0x11c >>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] >>>> el1_dbg+0x28/0x70 >>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] >>>> __do_softirq+0x1e8/0x480 >>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] >>>> __irq_exit_rcu+0xdc/0x140 >>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jessica Zhang >>>> >>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> >>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>>>> --- >>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- >>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ >>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ >>>>> 3 files changed, 16 insertions(+), 13 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c >>>>> index 9603193d2fa1..a2899af82b4a 100644 >>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, >>>>> int i, ret; >>>>> unsigned int crtc_mask = 0; >>>>> >>>>> - /* >>>>> - * Legacy cursor ioctls are completely unsynced, and userspace >>>>> - * relies on that (by doing tons of cursor updates). >>>>> - */ >>>>> - if (old_state->legacy_cursor_update) >>>>> - return; >>>>> - >>>>> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { >>>>> if (!new_crtc_state->active) >>>>> continue; >>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, >>>>> continue; >>>>> } >>>>> >>>>> - /* Legacy cursor updates are fully unsynced. */ >>>>> - if (state->legacy_cursor_update) { >>>>> - complete_all(&commit->flip_done); >>>>> - continue; >>>>> - } >>>>> - >>>>> if (!new_crtc_state->event) { >>>>> commit->event = kzalloc(sizeof(*commit->event), >>>>> GFP_KERNEL); >>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c >>>>> index d2abe0e430bf..6ca5a6e7703b 100644 >>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c >>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c >>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, >>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); >>>>> return ret; >>>>> } >>>>> + >>>>> + /* >>>>> + * FIXME: Cut over to (async) commit helpers instead of hand-rolling >>>>> + * everything. >>>>> + */ >>>>> + if (state->base.legacy_cursor_update) { >>>>> + struct intel_crtc_state *new_crtc_state; >>>>> + struct intel_crtc *crtc; >>>>> + int i; >>>>> + >>>>> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) >>>>> + complete_all(&new_crtc_state->uapi.commit->flip_done); >>>>> + } >>>>> + >>>>> intel_shared_dpll_swap_state(state); >>>>> intel_atomic_track_fbs(state); >>>>> >>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c >>>>> index 1686fbb611fd..b3cfabebe5d6 100644 >>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c >>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c >>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) >>>>> /* async updates are limited to single-crtc updates: */ >>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); >>>>> >>>>> + complete_all(&async_crtc->state->commit->flip_done); >>>>> + >>>>> /* >>>>> * Start timer if we don't already have an update pending >>>>> * on this crtc: >>>>> -- >>>>> 2.34.1 >>>>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-09 4:04 ` [Intel-gfx] " Abhinav Kumar @ 2022-04-12 23:36 ` Abhinav Kumar -1 siblings, 0 replies; 80+ messages in thread From: Abhinav Kumar @ 2022-04-12 23:36 UTC (permalink / raw) To: Rob Clark Cc: Rob Clark, Kalyan Thota, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development Hi Daniel On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > On 4/7/2022 4:12 PM, Rob Clark wrote: >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar >> <quic_abhinavk@quicinc.com> wrote: >>> >>> Hi Rob and Daniel >>> >>> On 4/7/2022 3:51 PM, Rob Clark wrote: >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang >>>> <quic_jesszhan@quicinc.com> wrote: >>>>> >>>>> >>>>> >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: >>>>>> The stuff never really worked, and leads to lots of fun because it >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other >>>>>> things. >>>>>> >>>>>> For async updates we now have a more solid solution with the >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for >>>>>> that >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit >>>>>> routines, doing something similar. >>>>>> >>>>>> For everyone else it's probably better to remove the use-after-free >>>>>> bug, and encourage folks to use the async support instead. The >>>>>> affected drivers which register a legacy cursor plane and don't >>>>>> either >>>>>> use the new async stuff or their own commit routine are: amdgpu, >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and >>>>>> vmwgfx. >>>>>> >>>>>> Inspired by an amdgpu bug report. >>>>>> >>>>>> v2: Drop RFC, I think with amdgpu converted over to use >>>>>> atomic_async_check/commit done in >>>>>> >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 >>>>>> >>>>>> drm/amd/display: Add fast path for cursor plane updates >>>>>> >>>>>> we don't have any driver anymore where we have userspace expecting >>>>>> solid legacy cursor support _and_ they are using the atomic >>>>>> helpers in >>>>>> their fully glory. So we can retire this. >>>>>> >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only >>>>>> thing missing afaict. >>>>>> >>>>>> v4: Fixup i915 fixup ... >>>>>> >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>>> References: >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ >>>>>> >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> >>>>>> Cc: mikita.lipski@amd.com >>>>>> Cc: Michel Dänzer <michel@daenzer.net> >>>>>> Cc: harry.wentland@amd.com >>>>>> Cc: Rob Clark <robdclark@gmail.com> >>>>> >>>>> Hey Rob, >>>>> >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, >>>>> what device did you test on? >>>> >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") >>>> >>>> I think the display setup shouldn't be significantly different than >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop >>>> ui.. I was mostly looking to make sure cursor movements weren't >>>> causing fps drops ;-) >>>> >>>> BR, >>>> -R >>> >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. >>> So we cannot let that break. >>> >>> I think we need to check whats causing this splat. >>> >>> Can we hold back this change till then? >> >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a >> loop of stop ui / start ui and hasn't triggered a splat yet. >> >> Otherwise maybe you can addr2line to figure out where it crashed? >> >> BR, >> -R > > So this is not a crash. Its a warning splat coming from > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > Looks like the complete_commit() which should signal the event has not > happened before the next cursor commit. > > Somehow this change is affecting the flow to miss the event signaling > that the event is done. > > We tried a couple of approaches but couldnt still fix the warning. > > Will continue to check further next week. > >> >>> Thanks >>> >>> Abhinav After checking this more this week, I think the current patch needs to be changed a bit. So, here you are removing the complete_all part and leaving that to the individual drivers, which is fine. But, you are also removing the continue part which I think seems incorrect and causing these warnings for MSM driver. @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } - /* Legacy cursor updates are fully unsynced. */ - if (state->legacy_cursor_update) { - complete_all(&commit->flip_done); - continue; - } - Thats because MSM driver thinks that if the previous crtc_state->event was not consumed, then something went wrong and throws a warning. if (!new_crtc_state->event) { commit->event = kzalloc(sizeof(*commit->event), GFP_KERNEL); if (!commit->event) return -ENOMEM; new_crtc_state->event = commit->event; } But for a cursor update, we should not or need not populate the event at all because it is async. So i think we should still keep the continue, rest of the patch is fine. @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } + if (state->legacy_cursor_update) + continue; + Let me know your comments. Thanks Abhinav >>>> >>>>> I'm hitting several instances of this error when doing a start/stop ui >>>>> on Lazor Chromebook with this patch: >>>>> >>>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W >>>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 >>>>> e5912cd286513b064a82a38938b3fdef86b079aa >>>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without >>>>> Touchscreen >>>>> (rev4) (DT) >>>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS >>>>> BTYPE=--) >>>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 >>>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 >>>>> [ 3092.647379] sp : ffffffc00c1e3760 >>>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: >>>>> 0000000000000425 >>>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: >>>>> ffffffdf8ae3b6f0 >>>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: >>>>> ffffff809b82da00 >>>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: >>>>> 0000000000001000 >>>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: >>>>> 000000000000003b >>>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: >>>>> 0000000000000003 >>>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : >>>>> 0000000000000040 >>>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : >>>>> 0000000000000004 >>>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : >>>>> 0000000000000000 >>>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : >>>>> ffffff809a1eb300 >>>>> [ 3092.724424] Call trace: >>>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 >>>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 >>>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 >>>>> [ 3092.741627] commit_tail+0x7c/0xfc >>>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c >>>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 >>>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 >>>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 >>>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c >>>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 >>>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c >>>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 >>>>> [ 3092.781770] drm_ioctl+0x320/0x370 >>>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc >>>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 >>>>> [ 3092.794030] invoke_syscall+0x80/0x114 >>>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 >>>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 >>>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 >>>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 >>>>> [ 3092.814914] el0t_32_sync+0x174/0x178 >>>>> [ 3092.818701] irq event stamp: 55940 >>>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] >>>>> exit_to_kernel_mode+0x10c/0x11c >>>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] >>>>> el1_dbg+0x28/0x70 >>>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] >>>>> __do_softirq+0x1e8/0x480 >>>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] >>>>> __irq_exit_rcu+0xdc/0x140 >>>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jessica Zhang >>>>> >>>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> >>>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>>>>> --- >>>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- >>>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ >>>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ >>>>>> 3 files changed, 16 insertions(+), 13 deletions(-) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >>>>>> b/drivers/gpu/drm/drm_atomic_helper.c >>>>>> index 9603193d2fa1..a2899af82b4a 100644 >>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct >>>>>> drm_device *dev, >>>>>> int i, ret; >>>>>> unsigned int crtc_mask = 0; >>>>>> >>>>>> - /* >>>>>> - * Legacy cursor ioctls are completely unsynced, and userspace >>>>>> - * relies on that (by doing tons of cursor updates). >>>>>> - */ >>>>>> - if (old_state->legacy_cursor_update) >>>>>> - return; >>>>>> - >>>>>> for_each_oldnew_crtc_in_state(old_state, crtc, >>>>>> old_crtc_state, new_crtc_state, i) { >>>>>> if (!new_crtc_state->active) >>>>>> continue; >>>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct >>>>>> drm_atomic_state *state, >>>>>> continue; >>>>>> } >>>>>> >>>>>> - /* Legacy cursor updates are fully unsynced. */ >>>>>> - if (state->legacy_cursor_update) { >>>>>> - complete_all(&commit->flip_done); >>>>>> - continue; >>>>>> - } >>>>>> - >>>>>> if (!new_crtc_state->event) { >>>>>> commit->event = >>>>>> kzalloc(sizeof(*commit->event), >>>>>> GFP_KERNEL); >>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c >>>>>> b/drivers/gpu/drm/i915/display/intel_display.c >>>>>> index d2abe0e430bf..6ca5a6e7703b 100644 >>>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c >>>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c >>>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct >>>>>> drm_device *dev, >>>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, >>>>>> state->wakeref); >>>>>> return ret; >>>>>> } >>>>>> + >>>>>> + /* >>>>>> + * FIXME: Cut over to (async) commit helpers instead of >>>>>> hand-rolling >>>>>> + * everything. >>>>>> + */ >>>>>> + if (state->base.legacy_cursor_update) { >>>>>> + struct intel_crtc_state *new_crtc_state; >>>>>> + struct intel_crtc *crtc; >>>>>> + int i; >>>>>> + >>>>>> + for_each_new_intel_crtc_in_state(state, crtc, >>>>>> new_crtc_state, i) >>>>>> + >>>>>> complete_all(&new_crtc_state->uapi.commit->flip_done); >>>>>> + } >>>>>> + >>>>>> intel_shared_dpll_swap_state(state); >>>>>> intel_atomic_track_fbs(state); >>>>>> >>>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c >>>>>> b/drivers/gpu/drm/msm/msm_atomic.c >>>>>> index 1686fbb611fd..b3cfabebe5d6 100644 >>>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c >>>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c >>>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct >>>>>> drm_atomic_state *state) >>>>>> /* async updates are limited to single-crtc >>>>>> updates: */ >>>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); >>>>>> >>>>>> + complete_all(&async_crtc->state->commit->flip_done); >>>>>> + >>>>>> /* >>>>>> * Start timer if we don't already have an update >>>>>> pending >>>>>> * on this crtc: >>>>>> -- >>>>>> 2.34.1 >>>>>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-12 23:36 ` Abhinav Kumar 0 siblings, 0 replies; 80+ messages in thread From: Abhinav Kumar @ 2022-04-12 23:36 UTC (permalink / raw) To: Rob Clark Cc: Rob Clark, Kalyan Thota, Daniel Vetter, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development Hi Daniel On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > On 4/7/2022 4:12 PM, Rob Clark wrote: >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar >> <quic_abhinavk@quicinc.com> wrote: >>> >>> Hi Rob and Daniel >>> >>> On 4/7/2022 3:51 PM, Rob Clark wrote: >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang >>>> <quic_jesszhan@quicinc.com> wrote: >>>>> >>>>> >>>>> >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: >>>>>> The stuff never really worked, and leads to lots of fun because it >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other >>>>>> things. >>>>>> >>>>>> For async updates we now have a more solid solution with the >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for >>>>>> that >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit >>>>>> routines, doing something similar. >>>>>> >>>>>> For everyone else it's probably better to remove the use-after-free >>>>>> bug, and encourage folks to use the async support instead. The >>>>>> affected drivers which register a legacy cursor plane and don't >>>>>> either >>>>>> use the new async stuff or their own commit routine are: amdgpu, >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and >>>>>> vmwgfx. >>>>>> >>>>>> Inspired by an amdgpu bug report. >>>>>> >>>>>> v2: Drop RFC, I think with amdgpu converted over to use >>>>>> atomic_async_check/commit done in >>>>>> >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 >>>>>> >>>>>> drm/amd/display: Add fast path for cursor plane updates >>>>>> >>>>>> we don't have any driver anymore where we have userspace expecting >>>>>> solid legacy cursor support _and_ they are using the atomic >>>>>> helpers in >>>>>> their fully glory. So we can retire this. >>>>>> >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only >>>>>> thing missing afaict. >>>>>> >>>>>> v4: Fixup i915 fixup ... >>>>>> >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>>> References: >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ >>>>>> >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> >>>>>> Cc: mikita.lipski@amd.com >>>>>> Cc: Michel Dänzer <michel@daenzer.net> >>>>>> Cc: harry.wentland@amd.com >>>>>> Cc: Rob Clark <robdclark@gmail.com> >>>>> >>>>> Hey Rob, >>>>> >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, >>>>> what device did you test on? >>>> >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") >>>> >>>> I think the display setup shouldn't be significantly different than >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop >>>> ui.. I was mostly looking to make sure cursor movements weren't >>>> causing fps drops ;-) >>>> >>>> BR, >>>> -R >>> >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. >>> So we cannot let that break. >>> >>> I think we need to check whats causing this splat. >>> >>> Can we hold back this change till then? >> >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a >> loop of stop ui / start ui and hasn't triggered a splat yet. >> >> Otherwise maybe you can addr2line to figure out where it crashed? >> >> BR, >> -R > > So this is not a crash. Its a warning splat coming from > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > Looks like the complete_commit() which should signal the event has not > happened before the next cursor commit. > > Somehow this change is affecting the flow to miss the event signaling > that the event is done. > > We tried a couple of approaches but couldnt still fix the warning. > > Will continue to check further next week. > >> >>> Thanks >>> >>> Abhinav After checking this more this week, I think the current patch needs to be changed a bit. So, here you are removing the complete_all part and leaving that to the individual drivers, which is fine. But, you are also removing the continue part which I think seems incorrect and causing these warnings for MSM driver. @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } - /* Legacy cursor updates are fully unsynced. */ - if (state->legacy_cursor_update) { - complete_all(&commit->flip_done); - continue; - } - Thats because MSM driver thinks that if the previous crtc_state->event was not consumed, then something went wrong and throws a warning. if (!new_crtc_state->event) { commit->event = kzalloc(sizeof(*commit->event), GFP_KERNEL); if (!commit->event) return -ENOMEM; new_crtc_state->event = commit->event; } But for a cursor update, we should not or need not populate the event at all because it is async. So i think we should still keep the continue, rest of the patch is fine. @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } + if (state->legacy_cursor_update) + continue; + Let me know your comments. Thanks Abhinav >>>> >>>>> I'm hitting several instances of this error when doing a start/stop ui >>>>> on Lazor Chromebook with this patch: >>>>> >>>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W >>>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 >>>>> e5912cd286513b064a82a38938b3fdef86b079aa >>>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without >>>>> Touchscreen >>>>> (rev4) (DT) >>>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS >>>>> BTYPE=--) >>>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 >>>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 >>>>> [ 3092.647379] sp : ffffffc00c1e3760 >>>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: >>>>> 0000000000000425 >>>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: >>>>> ffffffdf8ae3b6f0 >>>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: >>>>> ffffff809b82da00 >>>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: >>>>> 0000000000001000 >>>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: >>>>> 000000000000003b >>>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: >>>>> 0000000000000003 >>>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : >>>>> 0000000000000040 >>>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : >>>>> 0000000000000004 >>>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : >>>>> 0000000000000000 >>>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : >>>>> ffffff809a1eb300 >>>>> [ 3092.724424] Call trace: >>>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 >>>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 >>>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 >>>>> [ 3092.741627] commit_tail+0x7c/0xfc >>>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c >>>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 >>>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 >>>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 >>>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c >>>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 >>>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c >>>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 >>>>> [ 3092.781770] drm_ioctl+0x320/0x370 >>>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc >>>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 >>>>> [ 3092.794030] invoke_syscall+0x80/0x114 >>>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 >>>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 >>>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 >>>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 >>>>> [ 3092.814914] el0t_32_sync+0x174/0x178 >>>>> [ 3092.818701] irq event stamp: 55940 >>>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] >>>>> exit_to_kernel_mode+0x10c/0x11c >>>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] >>>>> el1_dbg+0x28/0x70 >>>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] >>>>> __do_softirq+0x1e8/0x480 >>>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] >>>>> __irq_exit_rcu+0xdc/0x140 >>>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jessica Zhang >>>>> >>>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> >>>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>>>>> --- >>>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- >>>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ >>>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ >>>>>> 3 files changed, 16 insertions(+), 13 deletions(-) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >>>>>> b/drivers/gpu/drm/drm_atomic_helper.c >>>>>> index 9603193d2fa1..a2899af82b4a 100644 >>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct >>>>>> drm_device *dev, >>>>>> int i, ret; >>>>>> unsigned int crtc_mask = 0; >>>>>> >>>>>> - /* >>>>>> - * Legacy cursor ioctls are completely unsynced, and userspace >>>>>> - * relies on that (by doing tons of cursor updates). >>>>>> - */ >>>>>> - if (old_state->legacy_cursor_update) >>>>>> - return; >>>>>> - >>>>>> for_each_oldnew_crtc_in_state(old_state, crtc, >>>>>> old_crtc_state, new_crtc_state, i) { >>>>>> if (!new_crtc_state->active) >>>>>> continue; >>>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct >>>>>> drm_atomic_state *state, >>>>>> continue; >>>>>> } >>>>>> >>>>>> - /* Legacy cursor updates are fully unsynced. */ >>>>>> - if (state->legacy_cursor_update) { >>>>>> - complete_all(&commit->flip_done); >>>>>> - continue; >>>>>> - } >>>>>> - >>>>>> if (!new_crtc_state->event) { >>>>>> commit->event = >>>>>> kzalloc(sizeof(*commit->event), >>>>>> GFP_KERNEL); >>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c >>>>>> b/drivers/gpu/drm/i915/display/intel_display.c >>>>>> index d2abe0e430bf..6ca5a6e7703b 100644 >>>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c >>>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c >>>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct >>>>>> drm_device *dev, >>>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, >>>>>> state->wakeref); >>>>>> return ret; >>>>>> } >>>>>> + >>>>>> + /* >>>>>> + * FIXME: Cut over to (async) commit helpers instead of >>>>>> hand-rolling >>>>>> + * everything. >>>>>> + */ >>>>>> + if (state->base.legacy_cursor_update) { >>>>>> + struct intel_crtc_state *new_crtc_state; >>>>>> + struct intel_crtc *crtc; >>>>>> + int i; >>>>>> + >>>>>> + for_each_new_intel_crtc_in_state(state, crtc, >>>>>> new_crtc_state, i) >>>>>> + >>>>>> complete_all(&new_crtc_state->uapi.commit->flip_done); >>>>>> + } >>>>>> + >>>>>> intel_shared_dpll_swap_state(state); >>>>>> intel_atomic_track_fbs(state); >>>>>> >>>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c >>>>>> b/drivers/gpu/drm/msm/msm_atomic.c >>>>>> index 1686fbb611fd..b3cfabebe5d6 100644 >>>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c >>>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c >>>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct >>>>>> drm_atomic_state *state) >>>>>> /* async updates are limited to single-crtc >>>>>> updates: */ >>>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); >>>>>> >>>>>> + complete_all(&async_crtc->state->commit->flip_done); >>>>>> + >>>>>> /* >>>>>> * Start timer if we don't already have an update >>>>>> pending >>>>>> * on this crtc: >>>>>> -- >>>>>> 2.34.1 >>>>>> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-12 23:36 ` [Intel-gfx] " Abhinav Kumar @ 2022-04-13 11:20 ` Daniel Vetter -1 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-13 11:20 UTC (permalink / raw) To: Abhinav Kumar Cc: Rob Clark, Kalyan Thota, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > Hi Daniel > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > >> <quic_abhinavk@quicinc.com> wrote: > >>> > >>> Hi Rob and Daniel > >>> > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > >>>> <quic_jesszhan@quicinc.com> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > >>>>>> The stuff never really worked, and leads to lots of fun because it > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > >>>>>> things. > >>>>>> > >>>>>> For async updates we now have a more solid solution with the > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > >>>>>> that > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > >>>>>> routines, doing something similar. > >>>>>> > >>>>>> For everyone else it's probably better to remove the use-after-free > >>>>>> bug, and encourage folks to use the async support instead. The > >>>>>> affected drivers which register a legacy cursor plane and don't > >>>>>> either > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > >>>>>> vmwgfx. > >>>>>> > >>>>>> Inspired by an amdgpu bug report. > >>>>>> > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > >>>>>> atomic_async_check/commit done in > >>>>>> > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > >>>>>> > >>>>>> drm/amd/display: Add fast path for cursor plane updates > >>>>>> > >>>>>> we don't have any driver anymore where we have userspace expecting > >>>>>> solid legacy cursor support _and_ they are using the atomic > >>>>>> helpers in > >>>>>> their fully glory. So we can retire this. > >>>>>> > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > >>>>>> thing missing afaict. > >>>>>> > >>>>>> v4: Fixup i915 fixup ... > >>>>>> > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>>>>> References: > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > >>>>>> > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > >>>>>> Cc: mikita.lipski@amd.com > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > >>>>>> Cc: harry.wentland@amd.com > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > >>>>> > >>>>> Hey Rob, > >>>>> > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > >>>>> what device did you test on? > >>>> > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > >>>> > >>>> I think the display setup shouldn't be significantly different than > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > >>>> ui.. I was mostly looking to make sure cursor movements weren't > >>>> causing fps drops ;-) > >>>> > >>>> BR, > >>>> -R > >>> > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > >>> So we cannot let that break. > >>> > >>> I think we need to check whats causing this splat. > >>> > >>> Can we hold back this change till then? > >> > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > >> loop of stop ui / start ui and hasn't triggered a splat yet. > >> > >> Otherwise maybe you can addr2line to figure out where it crashed? > >> > >> BR, > >> -R > > > > So this is not a crash. Its a warning splat coming from > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > Looks like the complete_commit() which should signal the event has not > > happened before the next cursor commit. > > > > Somehow this change is affecting the flow to miss the event signaling > > that the event is done. > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > Will continue to check further next week. > > > >> > >>> Thanks > >>> > >>> Abhinav > > After checking this more this week, I think the current patch needs to > be changed a bit. > > So, here you are removing the complete_all part and leaving that to the > individual drivers, which is fine. > > But, you are also removing the continue part which I think seems > incorrect and causing these warnings for MSM driver. > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > > Thats because MSM driver thinks that if the previous crtc_state->event > was not consumed, then something went wrong and throws a warning. > > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > if (!commit->event) > return -ENOMEM; > > new_crtc_state->event = commit->event; > } > > But for a cursor update, we should not or need not populate the event at > all because it is async. > > So i think we should still keep the continue, rest of the patch is fine. > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > drm_atomic_state *state, > continue; > } > > + if (state->legacy_cursor_update) > + continue; > + > > Let me know your comments. Thanks a lot for your excellent analysis. I need to think this through some more and figure out what exactly we should be doing. -Daniel > Thanks > > Abhinav > >>>> > >>>>> I'm hitting several instances of this error when doing a start/stop ui > >>>>> on Lazor Chromebook with this patch: > >>>>> > >>>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > >>>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > >>>>> e5912cd286513b064a82a38938b3fdef86b079aa > >>>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without > >>>>> Touchscreen > >>>>> (rev4) (DT) > >>>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > >>>>> BTYPE=--) > >>>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > >>>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > >>>>> [ 3092.647379] sp : ffffffc00c1e3760 > >>>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > >>>>> 0000000000000425 > >>>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > >>>>> ffffffdf8ae3b6f0 > >>>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > >>>>> ffffff809b82da00 > >>>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > >>>>> 0000000000001000 > >>>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > >>>>> 000000000000003b > >>>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > >>>>> 0000000000000003 > >>>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > >>>>> 0000000000000040 > >>>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > >>>>> 0000000000000004 > >>>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > >>>>> 0000000000000000 > >>>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > >>>>> ffffff809a1eb300 > >>>>> [ 3092.724424] Call trace: > >>>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > >>>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > >>>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > >>>>> [ 3092.741627] commit_tail+0x7c/0xfc > >>>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > >>>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 > >>>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > >>>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 > >>>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > >>>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > >>>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > >>>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > >>>>> [ 3092.781770] drm_ioctl+0x320/0x370 > >>>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc > >>>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > >>>>> [ 3092.794030] invoke_syscall+0x80/0x114 > >>>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > >>>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > >>>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 > >>>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > >>>>> [ 3092.814914] el0t_32_sync+0x174/0x178 > >>>>> [ 3092.818701] irq event stamp: 55940 > >>>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > >>>>> exit_to_kernel_mode+0x10c/0x11c > >>>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > >>>>> el1_dbg+0x28/0x70 > >>>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > >>>>> __do_softirq+0x1e8/0x480 > >>>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > >>>>> __irq_exit_rcu+0xdc/0x140 > >>>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Jessica Zhang > >>>>> > >>>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > >>>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > >>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > >>>>>> --- > >>>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > >>>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > >>>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > >>>>>> 3 files changed, 16 insertions(+), 13 deletions(-) > >>>>>> > >>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> b/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> index 9603193d2fa1..a2899af82b4a 100644 > >>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct > >>>>>> drm_device *dev, > >>>>>> int i, ret; > >>>>>> unsigned int crtc_mask = 0; > >>>>>> > >>>>>> - /* > >>>>>> - * Legacy cursor ioctls are completely unsynced, and userspace > >>>>>> - * relies on that (by doing tons of cursor updates). > >>>>>> - */ > >>>>>> - if (old_state->legacy_cursor_update) > >>>>>> - return; > >>>>>> - > >>>>>> for_each_oldnew_crtc_in_state(old_state, crtc, > >>>>>> old_crtc_state, new_crtc_state, i) { > >>>>>> if (!new_crtc_state->active) > >>>>>> continue; > >>>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > >>>>>> drm_atomic_state *state, > >>>>>> continue; > >>>>>> } > >>>>>> > >>>>>> - /* Legacy cursor updates are fully unsynced. */ > >>>>>> - if (state->legacy_cursor_update) { > >>>>>> - complete_all(&commit->flip_done); > >>>>>> - continue; > >>>>>> - } > >>>>>> - > >>>>>> if (!new_crtc_state->event) { > >>>>>> commit->event = > >>>>>> kzalloc(sizeof(*commit->event), > >>>>>> GFP_KERNEL); > >>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> b/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> index d2abe0e430bf..6ca5a6e7703b 100644 > >>>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct > >>>>>> drm_device *dev, > >>>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, > >>>>>> state->wakeref); > >>>>>> return ret; > >>>>>> } > >>>>>> + > >>>>>> + /* > >>>>>> + * FIXME: Cut over to (async) commit helpers instead of > >>>>>> hand-rolling > >>>>>> + * everything. > >>>>>> + */ > >>>>>> + if (state->base.legacy_cursor_update) { > >>>>>> + struct intel_crtc_state *new_crtc_state; > >>>>>> + struct intel_crtc *crtc; > >>>>>> + int i; > >>>>>> + > >>>>>> + for_each_new_intel_crtc_in_state(state, crtc, > >>>>>> new_crtc_state, i) > >>>>>> + > >>>>>> complete_all(&new_crtc_state->uapi.commit->flip_done); > >>>>>> + } > >>>>>> + > >>>>>> intel_shared_dpll_swap_state(state); > >>>>>> intel_atomic_track_fbs(state); > >>>>>> > >>>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> b/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> index 1686fbb611fd..b3cfabebe5d6 100644 > >>>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct > >>>>>> drm_atomic_state *state) > >>>>>> /* async updates are limited to single-crtc > >>>>>> updates: */ > >>>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > >>>>>> > >>>>>> + complete_all(&async_crtc->state->commit->flip_done); > >>>>>> + > >>>>>> /* > >>>>>> * Start timer if we don't already have an update > >>>>>> pending > >>>>>> * on this crtc: > >>>>>> -- > >>>>>> 2.34.1 > >>>>>> -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-13 11:20 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-13 11:20 UTC (permalink / raw) To: Abhinav Kumar Cc: Rob Clark, Kalyan Thota, Michel Dänzer, DRI Development, Kazlauskas, Nicholas, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > Hi Daniel > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > >> <quic_abhinavk@quicinc.com> wrote: > >>> > >>> Hi Rob and Daniel > >>> > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > >>>> <quic_jesszhan@quicinc.com> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > >>>>>> The stuff never really worked, and leads to lots of fun because it > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > >>>>>> things. > >>>>>> > >>>>>> For async updates we now have a more solid solution with the > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > >>>>>> that > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > >>>>>> routines, doing something similar. > >>>>>> > >>>>>> For everyone else it's probably better to remove the use-after-free > >>>>>> bug, and encourage folks to use the async support instead. The > >>>>>> affected drivers which register a legacy cursor plane and don't > >>>>>> either > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > >>>>>> vmwgfx. > >>>>>> > >>>>>> Inspired by an amdgpu bug report. > >>>>>> > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > >>>>>> atomic_async_check/commit done in > >>>>>> > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > >>>>>> > >>>>>> drm/amd/display: Add fast path for cursor plane updates > >>>>>> > >>>>>> we don't have any driver anymore where we have userspace expecting > >>>>>> solid legacy cursor support _and_ they are using the atomic > >>>>>> helpers in > >>>>>> their fully glory. So we can retire this. > >>>>>> > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > >>>>>> thing missing afaict. > >>>>>> > >>>>>> v4: Fixup i915 fixup ... > >>>>>> > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>>>>> References: > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > >>>>>> > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > >>>>>> Cc: mikita.lipski@amd.com > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > >>>>>> Cc: harry.wentland@amd.com > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > >>>>> > >>>>> Hey Rob, > >>>>> > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > >>>>> what device did you test on? > >>>> > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > >>>> > >>>> I think the display setup shouldn't be significantly different than > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > >>>> ui.. I was mostly looking to make sure cursor movements weren't > >>>> causing fps drops ;-) > >>>> > >>>> BR, > >>>> -R > >>> > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > >>> So we cannot let that break. > >>> > >>> I think we need to check whats causing this splat. > >>> > >>> Can we hold back this change till then? > >> > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > >> loop of stop ui / start ui and hasn't triggered a splat yet. > >> > >> Otherwise maybe you can addr2line to figure out where it crashed? > >> > >> BR, > >> -R > > > > So this is not a crash. Its a warning splat coming from > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > Looks like the complete_commit() which should signal the event has not > > happened before the next cursor commit. > > > > Somehow this change is affecting the flow to miss the event signaling > > that the event is done. > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > Will continue to check further next week. > > > >> > >>> Thanks > >>> > >>> Abhinav > > After checking this more this week, I think the current patch needs to > be changed a bit. > > So, here you are removing the complete_all part and leaving that to the > individual drivers, which is fine. > > But, you are also removing the continue part which I think seems > incorrect and causing these warnings for MSM driver. > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > > Thats because MSM driver thinks that if the previous crtc_state->event > was not consumed, then something went wrong and throws a warning. > > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > if (!commit->event) > return -ENOMEM; > > new_crtc_state->event = commit->event; > } > > But for a cursor update, we should not or need not populate the event at > all because it is async. > > So i think we should still keep the continue, rest of the patch is fine. > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > drm_atomic_state *state, > continue; > } > > + if (state->legacy_cursor_update) > + continue; > + > > Let me know your comments. Thanks a lot for your excellent analysis. I need to think this through some more and figure out what exactly we should be doing. -Daniel > Thanks > > Abhinav > >>>> > >>>>> I'm hitting several instances of this error when doing a start/stop ui > >>>>> on Lazor Chromebook with this patch: > >>>>> > >>>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > >>>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > >>>>> e5912cd286513b064a82a38938b3fdef86b079aa > >>>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without > >>>>> Touchscreen > >>>>> (rev4) (DT) > >>>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > >>>>> BTYPE=--) > >>>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > >>>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > >>>>> [ 3092.647379] sp : ffffffc00c1e3760 > >>>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > >>>>> 0000000000000425 > >>>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > >>>>> ffffffdf8ae3b6f0 > >>>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > >>>>> ffffff809b82da00 > >>>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > >>>>> 0000000000001000 > >>>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > >>>>> 000000000000003b > >>>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > >>>>> 0000000000000003 > >>>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > >>>>> 0000000000000040 > >>>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > >>>>> 0000000000000004 > >>>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > >>>>> 0000000000000000 > >>>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > >>>>> ffffff809a1eb300 > >>>>> [ 3092.724424] Call trace: > >>>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > >>>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > >>>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > >>>>> [ 3092.741627] commit_tail+0x7c/0xfc > >>>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > >>>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 > >>>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > >>>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 > >>>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > >>>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > >>>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > >>>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > >>>>> [ 3092.781770] drm_ioctl+0x320/0x370 > >>>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc > >>>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > >>>>> [ 3092.794030] invoke_syscall+0x80/0x114 > >>>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > >>>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > >>>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 > >>>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > >>>>> [ 3092.814914] el0t_32_sync+0x174/0x178 > >>>>> [ 3092.818701] irq event stamp: 55940 > >>>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > >>>>> exit_to_kernel_mode+0x10c/0x11c > >>>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > >>>>> el1_dbg+0x28/0x70 > >>>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > >>>>> __do_softirq+0x1e8/0x480 > >>>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > >>>>> __irq_exit_rcu+0xdc/0x140 > >>>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Jessica Zhang > >>>>> > >>>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > >>>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > >>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > >>>>>> --- > >>>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > >>>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > >>>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > >>>>>> 3 files changed, 16 insertions(+), 13 deletions(-) > >>>>>> > >>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> b/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> index 9603193d2fa1..a2899af82b4a 100644 > >>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c > >>>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct > >>>>>> drm_device *dev, > >>>>>> int i, ret; > >>>>>> unsigned int crtc_mask = 0; > >>>>>> > >>>>>> - /* > >>>>>> - * Legacy cursor ioctls are completely unsynced, and userspace > >>>>>> - * relies on that (by doing tons of cursor updates). > >>>>>> - */ > >>>>>> - if (old_state->legacy_cursor_update) > >>>>>> - return; > >>>>>> - > >>>>>> for_each_oldnew_crtc_in_state(old_state, crtc, > >>>>>> old_crtc_state, new_crtc_state, i) { > >>>>>> if (!new_crtc_state->active) > >>>>>> continue; > >>>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > >>>>>> drm_atomic_state *state, > >>>>>> continue; > >>>>>> } > >>>>>> > >>>>>> - /* Legacy cursor updates are fully unsynced. */ > >>>>>> - if (state->legacy_cursor_update) { > >>>>>> - complete_all(&commit->flip_done); > >>>>>> - continue; > >>>>>> - } > >>>>>> - > >>>>>> if (!new_crtc_state->event) { > >>>>>> commit->event = > >>>>>> kzalloc(sizeof(*commit->event), > >>>>>> GFP_KERNEL); > >>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> b/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> index d2abe0e430bf..6ca5a6e7703b 100644 > >>>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c > >>>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct > >>>>>> drm_device *dev, > >>>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, > >>>>>> state->wakeref); > >>>>>> return ret; > >>>>>> } > >>>>>> + > >>>>>> + /* > >>>>>> + * FIXME: Cut over to (async) commit helpers instead of > >>>>>> hand-rolling > >>>>>> + * everything. > >>>>>> + */ > >>>>>> + if (state->base.legacy_cursor_update) { > >>>>>> + struct intel_crtc_state *new_crtc_state; > >>>>>> + struct intel_crtc *crtc; > >>>>>> + int i; > >>>>>> + > >>>>>> + for_each_new_intel_crtc_in_state(state, crtc, > >>>>>> new_crtc_state, i) > >>>>>> + > >>>>>> complete_all(&new_crtc_state->uapi.commit->flip_done); > >>>>>> + } > >>>>>> + > >>>>>> intel_shared_dpll_swap_state(state); > >>>>>> intel_atomic_track_fbs(state); > >>>>>> > >>>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> b/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> index 1686fbb611fd..b3cfabebe5d6 100644 > >>>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c > >>>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct > >>>>>> drm_atomic_state *state) > >>>>>> /* async updates are limited to single-crtc > >>>>>> updates: */ > >>>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > >>>>>> > >>>>>> + complete_all(&async_crtc->state->commit->flip_done); > >>>>>> + > >>>>>> /* > >>>>>> * Start timer if we don't already have an update > >>>>>> pending > >>>>>> * on this crtc: > >>>>>> -- > >>>>>> 2.34.1 > >>>>>> -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-13 11:20 ` [Intel-gfx] " Daniel Vetter @ 2022-04-28 8:08 ` Maxime Ripard -1 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2022-04-28 8:08 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Kalyan Thota, Michel Dänzer, Abhinav Kumar, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development [-- Attachment #1: Type: text/plain, Size: 7119 bytes --] Hi Daniel, On Wed, Apr 13, 2022 at 01:20:11PM +0200, Daniel Vetter wrote: > On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > > >> <quic_abhinavk@quicinc.com> wrote: > > >>> > > >>> Hi Rob and Daniel > > >>> > > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > > >>>> <quic_jesszhan@quicinc.com> wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > >>>>>> The stuff never really worked, and leads to lots of fun because it > > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > > >>>>>> things. > > >>>>>> > > >>>>>> For async updates we now have a more solid solution with the > > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > > >>>>>> that > > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > > >>>>>> routines, doing something similar. > > >>>>>> > > >>>>>> For everyone else it's probably better to remove the use-after-free > > >>>>>> bug, and encourage folks to use the async support instead. The > > >>>>>> affected drivers which register a legacy cursor plane and don't > > >>>>>> either > > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > >>>>>> vmwgfx. > > >>>>>> > > >>>>>> Inspired by an amdgpu bug report. > > >>>>>> > > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > > >>>>>> atomic_async_check/commit done in > > >>>>>> > > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > > >>>>>> > > >>>>>> drm/amd/display: Add fast path for cursor plane updates > > >>>>>> > > >>>>>> we don't have any driver anymore where we have userspace expecting > > >>>>>> solid legacy cursor support _and_ they are using the atomic > > >>>>>> helpers in > > >>>>>> their fully glory. So we can retire this. > > >>>>>> > > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > > >>>>>> thing missing afaict. > > >>>>>> > > >>>>>> v4: Fixup i915 fixup ... > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> References: > > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Cc: mikita.lipski@amd.com > > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > > >>>>>> Cc: harry.wentland@amd.com > > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > > >>>>> > > >>>>> Hey Rob, > > >>>>> > > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > > >>>>> what device did you test on? > > >>>> > > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > >>>> > > >>>> I think the display setup shouldn't be significantly different than > > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > >>>> ui.. I was mostly looking to make sure cursor movements weren't > > >>>> causing fps drops ;-) > > >>>> > > >>>> BR, > > >>>> -R > > >>> > > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > > >>> So we cannot let that break. > > >>> > > >>> I think we need to check whats causing this splat. > > >>> > > >>> Can we hold back this change till then? > > >> > > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > > >> loop of stop ui / start ui and hasn't triggered a splat yet. > > >> > > >> Otherwise maybe you can addr2line to figure out where it crashed? > > >> > > >> BR, > > >> -R > > > > > > So this is not a crash. Its a warning splat coming from > > > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > > > > Looks like the complete_commit() which should signal the event has not > > > happened before the next cursor commit. > > > > > > Somehow this change is affecting the flow to miss the event signaling > > > that the event is done. > > > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > > > Will continue to check further next week. > > > > > >> > > >>> Thanks > > >>> > > >>> Abhinav > > > > After checking this more this week, I think the current patch needs to > > be changed a bit. > > > > So, here you are removing the complete_all part and leaving that to the > > individual drivers, which is fine. > > > > But, you are also removing the continue part which I think seems > > incorrect and causing these warnings for MSM driver. > > > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > > > Thats because MSM driver thinks that if the previous crtc_state->event > > was not consumed, then something went wrong and throws a warning. > > > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > if (!commit->event) > > return -ENOMEM; > > > > new_crtc_state->event = commit->event; > > } > > > > But for a cursor update, we should not or need not populate the event at > > all because it is async. > > > > So i think we should still keep the continue, rest of the patch is fine. > > > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > + if (state->legacy_cursor_update) > > + continue; > > + > > > > Let me know your comments. > > Thanks a lot for your excellent analysis. I need to think this through > some more and figure out what exactly we should be doing. We integrated this in the (downstream) RaspberryPi kernel, and it seems to trigger some weird regressions: - If we move the cursor under X, the primary plane update is stuck: https://github.com/raspberrypi/linux/issues/4988 - Switching back and forth between VT gets the kernel stuck (with a locking issue in fb_release?) https://github.com/raspberrypi/linux/issues/5011 I haven't been able to look into it at this point, I'll let you know if I find anything relevant Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-28 8:08 ` Maxime Ripard 0 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2022-04-28 8:08 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Kalyan Thota, Michel Dänzer, Abhinav Kumar, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development [-- Attachment #1: Type: text/plain, Size: 7119 bytes --] Hi Daniel, On Wed, Apr 13, 2022 at 01:20:11PM +0200, Daniel Vetter wrote: > On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > > >> <quic_abhinavk@quicinc.com> wrote: > > >>> > > >>> Hi Rob and Daniel > > >>> > > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > > >>>> <quic_jesszhan@quicinc.com> wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > >>>>>> The stuff never really worked, and leads to lots of fun because it > > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > > >>>>>> things. > > >>>>>> > > >>>>>> For async updates we now have a more solid solution with the > > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > > >>>>>> that > > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > > >>>>>> routines, doing something similar. > > >>>>>> > > >>>>>> For everyone else it's probably better to remove the use-after-free > > >>>>>> bug, and encourage folks to use the async support instead. The > > >>>>>> affected drivers which register a legacy cursor plane and don't > > >>>>>> either > > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > >>>>>> vmwgfx. > > >>>>>> > > >>>>>> Inspired by an amdgpu bug report. > > >>>>>> > > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > > >>>>>> atomic_async_check/commit done in > > >>>>>> > > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > > >>>>>> > > >>>>>> drm/amd/display: Add fast path for cursor plane updates > > >>>>>> > > >>>>>> we don't have any driver anymore where we have userspace expecting > > >>>>>> solid legacy cursor support _and_ they are using the atomic > > >>>>>> helpers in > > >>>>>> their fully glory. So we can retire this. > > >>>>>> > > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > > >>>>>> thing missing afaict. > > >>>>>> > > >>>>>> v4: Fixup i915 fixup ... > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> References: > > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Cc: mikita.lipski@amd.com > > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > > >>>>>> Cc: harry.wentland@amd.com > > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > > >>>>> > > >>>>> Hey Rob, > > >>>>> > > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > > >>>>> what device did you test on? > > >>>> > > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > >>>> > > >>>> I think the display setup shouldn't be significantly different than > > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > >>>> ui.. I was mostly looking to make sure cursor movements weren't > > >>>> causing fps drops ;-) > > >>>> > > >>>> BR, > > >>>> -R > > >>> > > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > > >>> So we cannot let that break. > > >>> > > >>> I think we need to check whats causing this splat. > > >>> > > >>> Can we hold back this change till then? > > >> > > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > > >> loop of stop ui / start ui and hasn't triggered a splat yet. > > >> > > >> Otherwise maybe you can addr2line to figure out where it crashed? > > >> > > >> BR, > > >> -R > > > > > > So this is not a crash. Its a warning splat coming from > > > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > > > > Looks like the complete_commit() which should signal the event has not > > > happened before the next cursor commit. > > > > > > Somehow this change is affecting the flow to miss the event signaling > > > that the event is done. > > > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > > > Will continue to check further next week. > > > > > >> > > >>> Thanks > > >>> > > >>> Abhinav > > > > After checking this more this week, I think the current patch needs to > > be changed a bit. > > > > So, here you are removing the complete_all part and leaving that to the > > individual drivers, which is fine. > > > > But, you are also removing the continue part which I think seems > > incorrect and causing these warnings for MSM driver. > > > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > > > Thats because MSM driver thinks that if the previous crtc_state->event > > was not consumed, then something went wrong and throws a warning. > > > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > if (!commit->event) > > return -ENOMEM; > > > > new_crtc_state->event = commit->event; > > } > > > > But for a cursor update, we should not or need not populate the event at > > all because it is async. > > > > So i think we should still keep the continue, rest of the patch is fine. > > > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > + if (state->legacy_cursor_update) > > + continue; > > + > > > > Let me know your comments. > > Thanks a lot for your excellent analysis. I need to think this through > some more and figure out what exactly we should be doing. We integrated this in the (downstream) RaspberryPi kernel, and it seems to trigger some weird regressions: - If we move the cursor under X, the primary plane update is stuck: https://github.com/raspberrypi/linux/issues/4988 - Switching back and forth between VT gets the kernel stuck (with a locking issue in fb_release?) https://github.com/raspberrypi/linux/issues/5011 I haven't been able to look into it at this point, I'll let you know if I find anything relevant Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-28 8:08 ` Maxime Ripard @ 2022-04-28 12:09 ` Daniel Vetter -1 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-28 12:09 UTC (permalink / raw) To: Maxime Ripard Cc: Rob Clark, Kalyan Thota, Daniel Vetter, Michel Dänzer, Abhinav Kumar, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On Thu, Apr 28, 2022 at 10:08:47AM +0200, Maxime Ripard wrote: > Hi Daniel, > > On Wed, Apr 13, 2022 at 01:20:11PM +0200, Daniel Vetter wrote: > > On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > > > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > > > >> <quic_abhinavk@quicinc.com> wrote: > > > >>> > > > >>> Hi Rob and Daniel > > > >>> > > > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > > > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > > > >>>> <quic_jesszhan@quicinc.com> wrote: > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > > >>>>>> The stuff never really worked, and leads to lots of fun because it > > > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > > > >>>>>> things. > > > >>>>>> > > > >>>>>> For async updates we now have a more solid solution with the > > > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > >>>>>> that > > > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > > > >>>>>> routines, doing something similar. > > > >>>>>> > > > >>>>>> For everyone else it's probably better to remove the use-after-free > > > >>>>>> bug, and encourage folks to use the async support instead. The > > > >>>>>> affected drivers which register a legacy cursor plane and don't > > > >>>>>> either > > > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > > > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > >>>>>> vmwgfx. > > > >>>>>> > > > >>>>>> Inspired by an amdgpu bug report. > > > >>>>>> > > > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > > > >>>>>> atomic_async_check/commit done in > > > >>>>>> > > > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > > > >>>>>> > > > >>>>>> drm/amd/display: Add fast path for cursor plane updates > > > >>>>>> > > > >>>>>> we don't have any driver anymore where we have userspace expecting > > > >>>>>> solid legacy cursor support _and_ they are using the atomic > > > >>>>>> helpers in > > > >>>>>> their fully glory. So we can retire this. > > > >>>>>> > > > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > > > >>>>>> thing missing afaict. > > > >>>>>> > > > >>>>>> v4: Fixup i915 fixup ... > > > >>>>>> > > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > > >>>>>> References: > > > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > > >>>>>> > > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > > > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > > > >>>>>> Cc: mikita.lipski@amd.com > > > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > > > >>>>>> Cc: harry.wentland@amd.com > > > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > > > >>>>> > > > >>>>> Hey Rob, > > > >>>>> > > > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > > > >>>>> what device did you test on? > > > >>>> > > > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > > >>>> > > > >>>> I think the display setup shouldn't be significantly different than > > > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > > >>>> ui.. I was mostly looking to make sure cursor movements weren't > > > >>>> causing fps drops ;-) > > > >>>> > > > >>>> BR, > > > >>>> -R > > > >>> > > > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > > > >>> So we cannot let that break. > > > >>> > > > >>> I think we need to check whats causing this splat. > > > >>> > > > >>> Can we hold back this change till then? > > > >> > > > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > > > >> loop of stop ui / start ui and hasn't triggered a splat yet. > > > >> > > > >> Otherwise maybe you can addr2line to figure out where it crashed? > > > >> > > > >> BR, > > > >> -R > > > > > > > > So this is not a crash. Its a warning splat coming from > > > > > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > > > > > > > Looks like the complete_commit() which should signal the event has not > > > > happened before the next cursor commit. > > > > > > > > Somehow this change is affecting the flow to miss the event signaling > > > > that the event is done. > > > > > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > > > > > Will continue to check further next week. > > > > > > > >> > > > >>> Thanks > > > >>> > > > >>> Abhinav > > > > > > After checking this more this week, I think the current patch needs to > > > be changed a bit. > > > > > > So, here you are removing the complete_all part and leaving that to the > > > individual drivers, which is fine. > > > > > > But, you are also removing the continue part which I think seems > > > incorrect and causing these warnings for MSM driver. > > > > > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > > drm_atomic_state *state, > > > continue; > > > } > > > > > > - /* Legacy cursor updates are fully unsynced. */ > > > - if (state->legacy_cursor_update) { > > > - complete_all(&commit->flip_done); > > > - continue; > > > - } > > > - > > > > > > Thats because MSM driver thinks that if the previous crtc_state->event > > > was not consumed, then something went wrong and throws a warning. > > > > > > if (!new_crtc_state->event) { > > > commit->event = kzalloc(sizeof(*commit->event), > > > GFP_KERNEL); > > > if (!commit->event) > > > return -ENOMEM; > > > > > > new_crtc_state->event = commit->event; > > > } > > > > > > But for a cursor update, we should not or need not populate the event at > > > all because it is async. > > > > > > So i think we should still keep the continue, rest of the patch is fine. > > > > > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > > > drm_atomic_state *state, > > > continue; > > > } > > > > > > + if (state->legacy_cursor_update) > > > + continue; > > > + > > > > > > Let me know your comments. > > > > Thanks a lot for your excellent analysis. I need to think this through > > some more and figure out what exactly we should be doing. > > We integrated this in the (downstream) RaspberryPi kernel, and it seems > to trigger some weird regressions: > > - If we move the cursor under X, the primary plane update is stuck: > https://github.com/raspberrypi/linux/issues/4988 > > - Switching back and forth between VT gets the kernel stuck (with a > locking issue in fb_release?) > https://github.com/raspberrypi/linux/issues/5011 > > I haven't been able to look into it at this point, I'll let you know if > I find anything relevant This sounds like we're dropping plane updates on the floor somehow when you move the cursor? I have honestly no idea how that's possible, can you try to figure this out? It should be entirely unrelated to the msm issue, which is really only about which one between helpers and msm is responsible for the even handling and cleanup. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-28 12:09 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-28 12:09 UTC (permalink / raw) To: Maxime Ripard Cc: Rob Clark, Kalyan Thota, Daniel Vetter, Michel Dänzer, Abhinav Kumar, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development On Thu, Apr 28, 2022 at 10:08:47AM +0200, Maxime Ripard wrote: > Hi Daniel, > > On Wed, Apr 13, 2022 at 01:20:11PM +0200, Daniel Vetter wrote: > > On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > > > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > > > >> <quic_abhinavk@quicinc.com> wrote: > > > >>> > > > >>> Hi Rob and Daniel > > > >>> > > > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > > > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > > > >>>> <quic_jesszhan@quicinc.com> wrote: > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > > >>>>>> The stuff never really worked, and leads to lots of fun because it > > > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > > > >>>>>> things. > > > >>>>>> > > > >>>>>> For async updates we now have a more solid solution with the > > > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > >>>>>> that > > > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > > > >>>>>> routines, doing something similar. > > > >>>>>> > > > >>>>>> For everyone else it's probably better to remove the use-after-free > > > >>>>>> bug, and encourage folks to use the async support instead. The > > > >>>>>> affected drivers which register a legacy cursor plane and don't > > > >>>>>> either > > > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > > > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > >>>>>> vmwgfx. > > > >>>>>> > > > >>>>>> Inspired by an amdgpu bug report. > > > >>>>>> > > > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > > > >>>>>> atomic_async_check/commit done in > > > >>>>>> > > > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > > > >>>>>> > > > >>>>>> drm/amd/display: Add fast path for cursor plane updates > > > >>>>>> > > > >>>>>> we don't have any driver anymore where we have userspace expecting > > > >>>>>> solid legacy cursor support _and_ they are using the atomic > > > >>>>>> helpers in > > > >>>>>> their fully glory. So we can retire this. > > > >>>>>> > > > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > > > >>>>>> thing missing afaict. > > > >>>>>> > > > >>>>>> v4: Fixup i915 fixup ... > > > >>>>>> > > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > > >>>>>> References: > > > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > > >>>>>> > > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > > > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > > > >>>>>> Cc: mikita.lipski@amd.com > > > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > > > >>>>>> Cc: harry.wentland@amd.com > > > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > > > >>>>> > > > >>>>> Hey Rob, > > > >>>>> > > > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > > > >>>>> what device did you test on? > > > >>>> > > > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > > >>>> > > > >>>> I think the display setup shouldn't be significantly different than > > > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > > >>>> ui.. I was mostly looking to make sure cursor movements weren't > > > >>>> causing fps drops ;-) > > > >>>> > > > >>>> BR, > > > >>>> -R > > > >>> > > > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > > > >>> So we cannot let that break. > > > >>> > > > >>> I think we need to check whats causing this splat. > > > >>> > > > >>> Can we hold back this change till then? > > > >> > > > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > > > >> loop of stop ui / start ui and hasn't triggered a splat yet. > > > >> > > > >> Otherwise maybe you can addr2line to figure out where it crashed? > > > >> > > > >> BR, > > > >> -R > > > > > > > > So this is not a crash. Its a warning splat coming from > > > > > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > > > > > > > Looks like the complete_commit() which should signal the event has not > > > > happened before the next cursor commit. > > > > > > > > Somehow this change is affecting the flow to miss the event signaling > > > > that the event is done. > > > > > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > > > > > Will continue to check further next week. > > > > > > > >> > > > >>> Thanks > > > >>> > > > >>> Abhinav > > > > > > After checking this more this week, I think the current patch needs to > > > be changed a bit. > > > > > > So, here you are removing the complete_all part and leaving that to the > > > individual drivers, which is fine. > > > > > > But, you are also removing the continue part which I think seems > > > incorrect and causing these warnings for MSM driver. > > > > > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > > drm_atomic_state *state, > > > continue; > > > } > > > > > > - /* Legacy cursor updates are fully unsynced. */ > > > - if (state->legacy_cursor_update) { > > > - complete_all(&commit->flip_done); > > > - continue; > > > - } > > > - > > > > > > Thats because MSM driver thinks that if the previous crtc_state->event > > > was not consumed, then something went wrong and throws a warning. > > > > > > if (!new_crtc_state->event) { > > > commit->event = kzalloc(sizeof(*commit->event), > > > GFP_KERNEL); > > > if (!commit->event) > > > return -ENOMEM; > > > > > > new_crtc_state->event = commit->event; > > > } > > > > > > But for a cursor update, we should not or need not populate the event at > > > all because it is async. > > > > > > So i think we should still keep the continue, rest of the patch is fine. > > > > > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > > > drm_atomic_state *state, > > > continue; > > > } > > > > > > + if (state->legacy_cursor_update) > > > + continue; > > > + > > > > > > Let me know your comments. > > > > Thanks a lot for your excellent analysis. I need to think this through > > some more and figure out what exactly we should be doing. > > We integrated this in the (downstream) RaspberryPi kernel, and it seems > to trigger some weird regressions: > > - If we move the cursor under X, the primary plane update is stuck: > https://github.com/raspberrypi/linux/issues/4988 > > - Switching back and forth between VT gets the kernel stuck (with a > locking issue in fb_release?) > https://github.com/raspberrypi/linux/issues/5011 > > I haven't been able to look into it at this point, I'll let you know if > I find anything relevant This sounds like we're dropping plane updates on the floor somehow when you move the cursor? I have honestly no idea how that's possible, can you try to figure this out? It should be entirely unrelated to the msm issue, which is really only about which one between helpers and msm is responsible for the even handling and cleanup. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-28 12:09 ` [Intel-gfx] " Daniel Vetter @ 2022-05-12 8:08 ` Maxime Ripard -1 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2022-05-12 8:08 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Kalyan Thota, Daniel Vetter, Michel Dänzer, Abhinav Kumar, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development [-- Attachment #1: Type: text/plain, Size: 794 bytes --] Hi Daniel, An update on this On Thu, Apr 28, 2022 at 02:09:40PM +0200, Daniel Vetter wrote: > > We integrated this in the (downstream) RaspberryPi kernel, and it seems > > to trigger some weird regressions: > > > > - If we move the cursor under X, the primary plane update is stuck: > > https://github.com/raspberrypi/linux/issues/4988 So it turns out the upstream driver doesn't seem affected by this, but only a downstream alternative. > > - Switching back and forth between VT gets the kernel stuck (with a > > locking issue in fb_release?) > > https://github.com/raspberrypi/linux/issues/5011 And this one turned out to be a separate issue fixed by Javier already. So as far as I'm concerned, this patch seems to be working fine on vc4 Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-05-12 8:08 ` Maxime Ripard 0 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2022-05-12 8:08 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Kalyan Thota, Daniel Vetter, Michel Dänzer, Abhinav Kumar, DRI Development, Kazlauskas, Nicholas, Dmitry Osipenko, Daniel Vetter, Jessica Zhang, Mikita Lipski, Intel Graphics Development [-- Attachment #1: Type: text/plain, Size: 794 bytes --] Hi Daniel, An update on this On Thu, Apr 28, 2022 at 02:09:40PM +0200, Daniel Vetter wrote: > > We integrated this in the (downstream) RaspberryPi kernel, and it seems > > to trigger some weird regressions: > > > > - If we move the cursor under X, the primary plane update is stuck: > > https://github.com/raspberrypi/linux/issues/4988 So it turns out the upstream driver doesn't seem affected by this, but only a downstream alternative. > > - Switching back and forth between VT gets the kernel stuck (with a > > locking issue in fb_release?) > > https://github.com/raspberrypi/linux/issues/5011 And this one turned out to be a separate issue fixed by Javier already. So as far as I'm concerned, this patch seems to be working fine on vc4 Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-13 11:20 ` [Intel-gfx] " Daniel Vetter @ 2022-09-26 15:06 ` Melissa Wen -1 siblings, 0 replies; 80+ messages in thread From: Melissa Wen @ 2022-09-26 15:06 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Kalyan Thota, Michel Dänzer, Abhinav Kumar, DRI Development, Maxime Ripard, Dmitry Osipenko, Jessica Zhang, Daniel Vetter, Mikita Lipski, Intel Graphics Development, Kazlauskas, Nicholas On 04/13, Daniel Vetter wrote: > On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > > Hi Daniel > > > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > > >> <quic_abhinavk@quicinc.com> wrote: > > >>> > > >>> Hi Rob and Daniel > > >>> > > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > > >>>> <quic_jesszhan@quicinc.com> wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > >>>>>> The stuff never really worked, and leads to lots of fun because it > > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > > >>>>>> things. > > >>>>>> > > >>>>>> For async updates we now have a more solid solution with the > > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > > >>>>>> that > > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > > >>>>>> routines, doing something similar. > > >>>>>> > > >>>>>> For everyone else it's probably better to remove the use-after-free > > >>>>>> bug, and encourage folks to use the async support instead. The > > >>>>>> affected drivers which register a legacy cursor plane and don't > > >>>>>> either > > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > >>>>>> vmwgfx. > > >>>>>> > > >>>>>> Inspired by an amdgpu bug report. > > >>>>>> > > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > > >>>>>> atomic_async_check/commit done in > > >>>>>> > > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > > >>>>>> > > >>>>>> drm/amd/display: Add fast path for cursor plane updates > > >>>>>> > > >>>>>> we don't have any driver anymore where we have userspace expecting > > >>>>>> solid legacy cursor support _and_ they are using the atomic > > >>>>>> helpers in > > >>>>>> their fully glory. So we can retire this. > > >>>>>> > > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > > >>>>>> thing missing afaict. > > >>>>>> > > >>>>>> v4: Fixup i915 fixup ... > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> References: > > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Cc: mikita.lipski@amd.com > > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > > >>>>>> Cc: harry.wentland@amd.com > > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > > >>>>> > > >>>>> Hey Rob, > > >>>>> > > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > > >>>>> what device did you test on? > > >>>> > > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > >>>> > > >>>> I think the display setup shouldn't be significantly different than > > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > >>>> ui.. I was mostly looking to make sure cursor movements weren't > > >>>> causing fps drops ;-) > > >>>> > > >>>> BR, > > >>>> -R > > >>> > > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > > >>> So we cannot let that break. > > >>> > > >>> I think we need to check whats causing this splat. > > >>> > > >>> Can we hold back this change till then? > > >> > > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > > >> loop of stop ui / start ui and hasn't triggered a splat yet. > > >> > > >> Otherwise maybe you can addr2line to figure out where it crashed? > > >> > > >> BR, > > >> -R > > > > > > So this is not a crash. Its a warning splat coming from > > > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > > > > Looks like the complete_commit() which should signal the event has not > > > happened before the next cursor commit. > > > > > > Somehow this change is affecting the flow to miss the event signaling > > > that the event is done. > > > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > > > Will continue to check further next week. > > > > > >> > > >>> Thanks > > >>> > > >>> Abhinav > > > > After checking this more this week, I think the current patch needs to > > be changed a bit. > > > > So, here you are removing the complete_all part and leaving that to the > > individual drivers, which is fine. > > > > But, you are also removing the continue part which I think seems > > incorrect and causing these warnings for MSM driver. > > > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > > > Thats because MSM driver thinks that if the previous crtc_state->event > > was not consumed, then something went wrong and throws a warning. > > > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > if (!commit->event) > > return -ENOMEM; > > > > new_crtc_state->event = commit->event; > > } > > > > But for a cursor update, we should not or need not populate the event at > > all because it is async. > > > > So i think we should still keep the continue, rest of the patch is fine. > > > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > + if (state->legacy_cursor_update) > > + continue; > > + > > > > Let me know your comments. > > Thanks a lot for your excellent analysis. I need to think this through > some more and figure out what exactly we should be doing. > -Daniel Hi, I was checking drm-misc-next state using a HDMI 4k in a Raspberry Pi 4 and I see part of the screen being corrupted by moving the cursor to the corners and bottom area - using drm-misc-next (a70abdd994c) + x11 + `disable_overscan=1`. So, Maxime pointed this patch to me and, indeed, it solves the issue. I wonder if there is any chance of having this (or a next version) upstream. Thanks, Melissa > > > Thanks > > > > Abhinav > > >>>> > > >>>>> I'm hitting several instances of this error when doing a start/stop ui > > >>>>> on Lazor Chromebook with this patch: > > >>>>> > > >>>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > > >>>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > > >>>>> e5912cd286513b064a82a38938b3fdef86b079aa > > >>>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without > > >>>>> Touchscreen > > >>>>> (rev4) (DT) > > >>>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > > >>>>> BTYPE=--) > > >>>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > > >>>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > > >>>>> [ 3092.647379] sp : ffffffc00c1e3760 > > >>>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > > >>>>> 0000000000000425 > > >>>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > > >>>>> ffffffdf8ae3b6f0 > > >>>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > > >>>>> ffffff809b82da00 > > >>>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > > >>>>> 0000000000001000 > > >>>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > > >>>>> 000000000000003b > > >>>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > > >>>>> 0000000000000003 > > >>>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > > >>>>> 0000000000000040 > > >>>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > > >>>>> 0000000000000004 > > >>>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > > >>>>> 0000000000000000 > > >>>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > > >>>>> ffffff809a1eb300 > > >>>>> [ 3092.724424] Call trace: > > >>>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > > >>>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > > >>>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > > >>>>> [ 3092.741627] commit_tail+0x7c/0xfc > > >>>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > > >>>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 > > >>>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > > >>>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 > > >>>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > > >>>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > > >>>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > > >>>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > > >>>>> [ 3092.781770] drm_ioctl+0x320/0x370 > > >>>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc > > >>>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > > >>>>> [ 3092.794030] invoke_syscall+0x80/0x114 > > >>>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > > >>>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > > >>>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 > > >>>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > > >>>>> [ 3092.814914] el0t_32_sync+0x174/0x178 > > >>>>> [ 3092.818701] irq event stamp: 55940 > > >>>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > > >>>>> exit_to_kernel_mode+0x10c/0x11c > > >>>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > > >>>>> el1_dbg+0x28/0x70 > > >>>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > > >>>>> __do_softirq+0x1e8/0x480 > > >>>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > > >>>>> __irq_exit_rcu+0xdc/0x140 > > >>>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>>> Jessica Zhang > > >>>>> > > >>>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > >>>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > >>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > >>>>>> --- > > >>>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > >>>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > >>>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > >>>>>> 3 files changed, 16 insertions(+), 13 deletions(-) > > >>>>>> > > >>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> b/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> index 9603193d2fa1..a2899af82b4a 100644 > > >>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct > > >>>>>> drm_device *dev, > > >>>>>> int i, ret; > > >>>>>> unsigned int crtc_mask = 0; > > >>>>>> > > >>>>>> - /* > > >>>>>> - * Legacy cursor ioctls are completely unsynced, and userspace > > >>>>>> - * relies on that (by doing tons of cursor updates). > > >>>>>> - */ > > >>>>>> - if (old_state->legacy_cursor_update) > > >>>>>> - return; > > >>>>>> - > > >>>>>> for_each_oldnew_crtc_in_state(old_state, crtc, > > >>>>>> old_crtc_state, new_crtc_state, i) { > > >>>>>> if (!new_crtc_state->active) > > >>>>>> continue; > > >>>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > >>>>>> drm_atomic_state *state, > > >>>>>> continue; > > >>>>>> } > > >>>>>> > > >>>>>> - /* Legacy cursor updates are fully unsynced. */ > > >>>>>> - if (state->legacy_cursor_update) { > > >>>>>> - complete_all(&commit->flip_done); > > >>>>>> - continue; > > >>>>>> - } > > >>>>>> - > > >>>>>> if (!new_crtc_state->event) { > > >>>>>> commit->event = > > >>>>>> kzalloc(sizeof(*commit->event), > > >>>>>> GFP_KERNEL); > > >>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> b/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> index d2abe0e430bf..6ca5a6e7703b 100644 > > >>>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct > > >>>>>> drm_device *dev, > > >>>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, > > >>>>>> state->wakeref); > > >>>>>> return ret; > > >>>>>> } > > >>>>>> + > > >>>>>> + /* > > >>>>>> + * FIXME: Cut over to (async) commit helpers instead of > > >>>>>> hand-rolling > > >>>>>> + * everything. > > >>>>>> + */ > > >>>>>> + if (state->base.legacy_cursor_update) { > > >>>>>> + struct intel_crtc_state *new_crtc_state; > > >>>>>> + struct intel_crtc *crtc; > > >>>>>> + int i; > > >>>>>> + > > >>>>>> + for_each_new_intel_crtc_in_state(state, crtc, > > >>>>>> new_crtc_state, i) > > >>>>>> + > > >>>>>> complete_all(&new_crtc_state->uapi.commit->flip_done); > > >>>>>> + } > > >>>>>> + > > >>>>>> intel_shared_dpll_swap_state(state); > > >>>>>> intel_atomic_track_fbs(state); > > >>>>>> > > >>>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> b/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> index 1686fbb611fd..b3cfabebe5d6 100644 > > >>>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct > > >>>>>> drm_atomic_state *state) > > >>>>>> /* async updates are limited to single-crtc > > >>>>>> updates: */ > > >>>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > >>>>>> > > >>>>>> + complete_all(&async_crtc->state->commit->flip_done); > > >>>>>> + > > >>>>>> /* > > >>>>>> * Start timer if we don't already have an update > > >>>>>> pending > > >>>>>> * on this crtc: > > >>>>>> -- > > >>>>>> 2.34.1 > > >>>>>> > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-09-26 15:06 ` Melissa Wen 0 siblings, 0 replies; 80+ messages in thread From: Melissa Wen @ 2022-09-26 15:06 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Kalyan Thota, Michel Dänzer, Abhinav Kumar, DRI Development, Maxime Ripard, Dmitry Osipenko, Jessica Zhang, Daniel Vetter, Mikita Lipski, Intel Graphics Development, Kazlauskas, Nicholas On 04/13, Daniel Vetter wrote: > On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > > Hi Daniel > > > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote: > > > > > > > > > On 4/7/2022 4:12 PM, Rob Clark wrote: > > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar > > >> <quic_abhinavk@quicinc.com> wrote: > > >>> > > >>> Hi Rob and Daniel > > >>> > > >>> On 4/7/2022 3:51 PM, Rob Clark wrote: > > >>>> On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang > > >>>> <quic_jesszhan@quicinc.com> wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 3/31/2022 8:20 AM, Daniel Vetter wrote: > > >>>>>> The stuff never really worked, and leads to lots of fun because it > > >>>>>> out-of-order frees atomic states. Which upsets KASAN, among other > > >>>>>> things. > > >>>>>> > > >>>>>> For async updates we now have a more solid solution with the > > >>>>>> ->atomic_async_check and ->atomic_async_commit hooks. Support for > > >>>>>> that > > >>>>>> for msm and vc4 landed. nouveau and i915 have their own commit > > >>>>>> routines, doing something similar. > > >>>>>> > > >>>>>> For everyone else it's probably better to remove the use-after-free > > >>>>>> bug, and encourage folks to use the async support instead. The > > >>>>>> affected drivers which register a legacy cursor plane and don't > > >>>>>> either > > >>>>>> use the new async stuff or their own commit routine are: amdgpu, > > >>>>>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > >>>>>> vmwgfx. > > >>>>>> > > >>>>>> Inspired by an amdgpu bug report. > > >>>>>> > > >>>>>> v2: Drop RFC, I think with amdgpu converted over to use > > >>>>>> atomic_async_check/commit done in > > >>>>>> > > >>>>>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > >>>>>> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > >>>>>> Date: Wed Dec 5 14:59:07 2018 -0500 > > >>>>>> > > >>>>>> drm/amd/display: Add fast path for cursor plane updates > > >>>>>> > > >>>>>> we don't have any driver anymore where we have userspace expecting > > >>>>>> solid legacy cursor support _and_ they are using the atomic > > >>>>>> helpers in > > >>>>>> their fully glory. So we can retire this. > > >>>>>> > > >>>>>> v3: Paper over msm and i915 regression. The complete_all is the only > > >>>>>> thing missing afaict. > > >>>>>> > > >>>>>> v4: Fixup i915 fixup ... > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> References: > > >>>>>> https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > >>>>>> > > >>>>>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >>>>>> Cc: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Tested-by: Maxime Ripard <maxime@cerno.tech> > > >>>>>> Cc: mikita.lipski@amd.com > > >>>>>> Cc: Michel Dänzer <michel@daenzer.net> > > >>>>>> Cc: harry.wentland@amd.com > > >>>>>> Cc: Rob Clark <robdclark@gmail.com> > > >>>>> > > >>>>> Hey Rob, > > >>>>> > > >>>>> I saw your tested-by and reviewed-by tags on Patchwork. Just curious, > > >>>>> what device did you test on? > > >>>> > > >>>> I was testing on strongbad.. v5.18-rc1 + patches (notably, revert > > >>>> 80253168dbfd ("drm: of: Lookup if child node has panel or bridge") > > >>>> > > >>>> I think the display setup shouldn't be significantly different than > > >>>> limozeen (ie. it's an eDP panel). But I didn't do much start/stop > > >>>> ui.. I was mostly looking to make sure cursor movements weren't > > >>>> causing fps drops ;-) > > >>>> > > >>>> BR, > > >>>> -R > > >>> > > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next. > > >>> So we cannot let that break. > > >>> > > >>> I think we need to check whats causing this splat. > > >>> > > >>> Can we hold back this change till then? > > >> > > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a > > >> loop of stop ui / start ui and hasn't triggered a splat yet. > > >> > > >> Otherwise maybe you can addr2line to figure out where it crashed? > > >> > > >> BR, > > >> -R > > > > > > So this is not a crash. Its a warning splat coming from > > > > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785 > > > > > > > > > Looks like the complete_commit() which should signal the event has not > > > happened before the next cursor commit. > > > > > > Somehow this change is affecting the flow to miss the event signaling > > > that the event is done. > > > > > > We tried a couple of approaches but couldnt still fix the warning. > > > > > > Will continue to check further next week. > > > > > >> > > >>> Thanks > > >>> > > >>> Abhinav > > > > After checking this more this week, I think the current patch needs to > > be changed a bit. > > > > So, here you are removing the complete_all part and leaving that to the > > individual drivers, which is fine. > > > > But, you are also removing the continue part which I think seems > > incorrect and causing these warnings for MSM driver. > > > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > > > Thats because MSM driver thinks that if the previous crtc_state->event > > was not consumed, then something went wrong and throws a warning. > > > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > if (!commit->event) > > return -ENOMEM; > > > > new_crtc_state->event = commit->event; > > } > > > > But for a cursor update, we should not or need not populate the event at > > all because it is async. > > > > So i think we should still keep the continue, rest of the patch is fine. > > > > @@ -2128,6 +2128,9 @@ int drm_atomic_helper_setup_commit(struct > > drm_atomic_state *state, > > continue; > > } > > > > + if (state->legacy_cursor_update) > > + continue; > > + > > > > Let me know your comments. > > Thanks a lot for your excellent analysis. I need to think this through > some more and figure out what exactly we should be doing. > -Daniel Hi, I was checking drm-misc-next state using a HDMI 4k in a Raspberry Pi 4 and I see part of the screen being corrupted by moving the cursor to the corners and bottom area - using drm-misc-next (a70abdd994c) + x11 + `disable_overscan=1`. So, Maxime pointed this patch to me and, indeed, it solves the issue. I wonder if there is any chance of having this (or a next version) upstream. Thanks, Melissa > > > Thanks > > > > Abhinav > > >>>> > > >>>>> I'm hitting several instances of this error when doing a start/stop ui > > >>>>> on Lazor Chromebook with this patch: > > >>>>> > > >>>>> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: G W > > >>>>> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > > >>>>> e5912cd286513b064a82a38938b3fdef86b079aa > > >>>>> [ 3092.622880] Hardware name: Google Lazor Limozeen without > > >>>>> Touchscreen > > >>>>> (rev4) (DT) > > >>>>> [ 3092.630492] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS > > >>>>> BTYPE=--) > > >>>>> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144 > > >>>>> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144 > > >>>>> [ 3092.647379] sp : ffffffc00c1e3760 > > >>>>> [ 3092.650805] x29: ffffffc00c1e3760 x28: ffffff80985dd800 x27: > > >>>>> 0000000000000425 > > >>>>> [ 3092.658164] x26: ffffff80985dc500 x25: ffffff80985ddc00 x24: > > >>>>> ffffffdf8ae3b6f0 > > >>>>> [ 3092.665522] x23: 0000000000000000 x22: 0000000000000000 x21: > > >>>>> ffffff809b82da00 > > >>>>> [ 3092.672890] x20: ffffff80840e1000 x19: ffffff80840e2000 x18: > > >>>>> 0000000000001000 > > >>>>> [ 3092.680255] x17: 0000000000000400 x16: 0000000000000100 x15: > > >>>>> 000000000000003b > > >>>>> [ 3092.687622] x14: 0000000000000000 x13: 0000000000000002 x12: > > >>>>> 0000000000000003 > > >>>>> [ 3092.694979] x11: ffffff8084009000 x10: 0000000000000040 x9 : > > >>>>> 0000000000000040 > > >>>>> [ 3092.702340] x8 : 0000000000000300 x7 : 000000000000000c x6 : > > >>>>> 0000000000000004 > > >>>>> [ 3092.709698] x5 : 0000000000000320 x4 : 0000000000000018 x3 : > > >>>>> 0000000000000000 > > >>>>> [ 3092.717056] x2 : 0000000000000000 x1 : 7bfb38b2a3a89800 x0 : > > >>>>> ffffff809a1eb300 > > >>>>> [ 3092.724424] Call trace: > > >>>>> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144 > > >>>>> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4 > > >>>>> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0 > > >>>>> [ 3092.741627] commit_tail+0x7c/0xfc > > >>>>> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c > > >>>>> [ 3092.749998] drm_atomic_commit+0x60/0x74 > > >>>>> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110 > > >>>>> [ 3092.759449] __setplane_atomic+0x11c/0x120 > > >>>>> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c > > >>>>> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8 > > >>>>> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c > > >>>>> [ 3092.777721] drm_ioctl_kernel+0xe8/0x168 > > >>>>> [ 3092.781770] drm_ioctl+0x320/0x370 > > >>>>> [ 3092.785289] drm_compat_ioctl+0x40/0xdc > > >>>>> [ 3092.789257] __arm64_compat_sys_ioctl+0xe0/0x150 > > >>>>> [ 3092.794030] invoke_syscall+0x80/0x114 > > >>>>> [ 3092.797905] el0_svc_common.constprop.3+0xc4/0xf8 > > >>>>> [ 3092.802765] do_el0_svc_compat+0x2c/0x54 > > >>>>> [ 3092.806811] el0_svc_compat+0x4c/0xe4 > > >>>>> [ 3092.810598] el0t_32_sync_handler+0xc4/0xf4 > > >>>>> [ 3092.814914] el0t_32_sync+0x174/0x178 > > >>>>> [ 3092.818701] irq event stamp: 55940 > > >>>>> [ 3092.822217] hardirqs last enabled at (55939): [<ffffffdf8ad617a4>] > > >>>>> exit_to_kernel_mode+0x10c/0x11c > > >>>>> [ 3092.831523] hardirqs last disabled at (55940): [<ffffffdf8ad62728>] > > >>>>> el1_dbg+0x28/0x70 > > >>>>> [ 3092.839577] softirqs last enabled at (55938): [<ffffffdf8a2103a8>] > > >>>>> __do_softirq+0x1e8/0x480 > > >>>>> [ 3092.848256] softirqs last disabled at (55923): [<ffffffdf8a28d668>] > > >>>>> __irq_exit_rcu+0xdc/0x140 > > >>>>> [ 3092.857022] ---[ end trace 0000000000000000 ]--- > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>>> Jessica Zhang > > >>>>> > > >>>>>> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > >>>>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > >>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > >>>>>> --- > > >>>>>> drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > >>>>>> drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > >>>>>> drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > >>>>>> 3 files changed, 16 insertions(+), 13 deletions(-) > > >>>>>> > > >>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> b/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> index 9603193d2fa1..a2899af82b4a 100644 > > >>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c > > >>>>>> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct > > >>>>>> drm_device *dev, > > >>>>>> int i, ret; > > >>>>>> unsigned int crtc_mask = 0; > > >>>>>> > > >>>>>> - /* > > >>>>>> - * Legacy cursor ioctls are completely unsynced, and userspace > > >>>>>> - * relies on that (by doing tons of cursor updates). > > >>>>>> - */ > > >>>>>> - if (old_state->legacy_cursor_update) > > >>>>>> - return; > > >>>>>> - > > >>>>>> for_each_oldnew_crtc_in_state(old_state, crtc, > > >>>>>> old_crtc_state, new_crtc_state, i) { > > >>>>>> if (!new_crtc_state->active) > > >>>>>> continue; > > >>>>>> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct > > >>>>>> drm_atomic_state *state, > > >>>>>> continue; > > >>>>>> } > > >>>>>> > > >>>>>> - /* Legacy cursor updates are fully unsynced. */ > > >>>>>> - if (state->legacy_cursor_update) { > > >>>>>> - complete_all(&commit->flip_done); > > >>>>>> - continue; > > >>>>>> - } > > >>>>>> - > > >>>>>> if (!new_crtc_state->event) { > > >>>>>> commit->event = > > >>>>>> kzalloc(sizeof(*commit->event), > > >>>>>> GFP_KERNEL); > > >>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> b/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> index d2abe0e430bf..6ca5a6e7703b 100644 > > >>>>>> --- a/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c > > >>>>>> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct > > >>>>>> drm_device *dev, > > >>>>>> intel_runtime_pm_put(&dev_priv->runtime_pm, > > >>>>>> state->wakeref); > > >>>>>> return ret; > > >>>>>> } > > >>>>>> + > > >>>>>> + /* > > >>>>>> + * FIXME: Cut over to (async) commit helpers instead of > > >>>>>> hand-rolling > > >>>>>> + * everything. > > >>>>>> + */ > > >>>>>> + if (state->base.legacy_cursor_update) { > > >>>>>> + struct intel_crtc_state *new_crtc_state; > > >>>>>> + struct intel_crtc *crtc; > > >>>>>> + int i; > > >>>>>> + > > >>>>>> + for_each_new_intel_crtc_in_state(state, crtc, > > >>>>>> new_crtc_state, i) > > >>>>>> + > > >>>>>> complete_all(&new_crtc_state->uapi.commit->flip_done); > > >>>>>> + } > > >>>>>> + > > >>>>>> intel_shared_dpll_swap_state(state); > > >>>>>> intel_atomic_track_fbs(state); > > >>>>>> > > >>>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> b/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> index 1686fbb611fd..b3cfabebe5d6 100644 > > >>>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c > > >>>>>> @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct > > >>>>>> drm_atomic_state *state) > > >>>>>> /* async updates are limited to single-crtc > > >>>>>> updates: */ > > >>>>>> WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > >>>>>> > > >>>>>> + complete_all(&async_crtc->state->commit->flip_done); > > >>>>>> + > > >>>>>> /* > > >>>>>> * Start timer if we don't already have an update > > >>>>>> pending > > >>>>>> * on this crtc: > > >>>>>> -- > > >>>>>> 2.34.1 > > >>>>>> > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter @ 2022-04-07 7:49 ` Thomas Zimmermann -1 siblings, 0 replies; 80+ messages in thread From: Thomas Zimmermann @ 2022-04-07 7:49 UTC (permalink / raw) To: Daniel Vetter, DRI Development, KuoHsiang Chou Cc: Michel Dänzer, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas [-- Attachment #1.1: Type: text/plain, Size: 5656 bytes --] Hi Daniel Am 31.03.22 um 17:20 schrieb Daniel Vetter: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. A while ago, I received a patch for a bug in ast. Cursor movement interfered with modesetting. [1] I didn't really knew what to make of it. Could this be related to the problem you're describing here? I guess the correct fix would be to implement async operations for cursor planes? ast doesn't do this yet. Best regards Thomas [1] https://lore.kernel.org/dri-devel/20210917072226.17357-1-kuohsiang_chou@aspeedtech.com/ > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > 3 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index 9603193d2fa1..a2899af82b4a 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index d2abe0e430bf..6ca5a6e7703b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b3cfabebe5d6 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-07 7:49 ` Thomas Zimmermann 0 siblings, 0 replies; 80+ messages in thread From: Thomas Zimmermann @ 2022-04-07 7:49 UTC (permalink / raw) To: Daniel Vetter, DRI Development, KuoHsiang Chou Cc: Michel Dänzer, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas [-- Attachment #1.1: Type: text/plain, Size: 5656 bytes --] Hi Daniel Am 31.03.22 um 17:20 schrieb Daniel Vetter: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. A while ago, I received a patch for a bug in ast. Cursor movement interfered with modesetting. [1] I didn't really knew what to make of it. Could this be related to the problem you're describing here? I guess the correct fix would be to implement async operations for cursor planes? ast doesn't do this yet. Best regards Thomas [1] https://lore.kernel.org/dri-devel/20210917072226.17357-1-kuohsiang_chou@aspeedtech.com/ > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > 3 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index 9603193d2fa1..a2899af82b4a 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index d2abe0e430bf..6ca5a6e7703b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b3cfabebe5d6 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2022-04-07 7:49 ` Thomas Zimmermann @ 2022-04-07 9:30 ` Daniel Vetter -1 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-07 9:30 UTC (permalink / raw) To: Thomas Zimmermann Cc: Daniel Vetter, Michel Dänzer, DRI Development, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas On Thu, Apr 07, 2022 at 09:49:49AM +0200, Thomas Zimmermann wrote: > Hi Daniel > > Am 31.03.22 um 17:20 schrieb Daniel Vetter: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > A while ago, I received a patch for a bug in ast. Cursor movement interfered > with modesetting. [1] I didn't really knew what to make of it. Could this be > related to the problem you're describing here? Maybe. > I guess the correct fix would be to implement async operations for cursor > planes? ast doesn't do this yet. Yeah the async ops are the new attempt (since a few years) to make this work and suck less. -Daniel > > Best regards > Thomas > > [1] https://lore.kernel.org/dri-devel/20210917072226.17357-1-kuohsiang_chou@aspeedtech.com/ > > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > 3 files changed, 16 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index 9603193d2fa1..a2899af82b4a 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index d2abe0e430bf..6ca5a6e7703b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b3cfabebe5d6 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2022-04-07 9:30 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2022-04-07 9:30 UTC (permalink / raw) To: Thomas Zimmermann Cc: Daniel Vetter, Michel Dänzer, DRI Development, KuoHsiang Chou, Maxime Ripard, Dmitry Osipenko, Daniel Vetter, mikita.lipski, Intel Graphics Development, Kazlauskas, Nicholas On Thu, Apr 07, 2022 at 09:49:49AM +0200, Thomas Zimmermann wrote: > Hi Daniel > > Am 31.03.22 um 17:20 schrieb Daniel Vetter: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > A while ago, I received a patch for a bug in ast. Cursor movement interfered > with modesetting. [1] I didn't really knew what to make of it. Could this be > related to the problem you're describing here? Maybe. > I guess the correct fix would be to implement async operations for cursor > planes? ast doesn't do this yet. Yeah the async ops are the new attempt (since a few years) to make this work and suck less. -Daniel > > Best regards > Thomas > > [1] https://lore.kernel.org/dri-devel/20210917072226.17357-1-kuohsiang_chou@aspeedtech.com/ > > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 2 ++ > > 3 files changed, 16 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index 9603193d2fa1..a2899af82b4a 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index d2abe0e430bf..6ca5a6e7703b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b3cfabebe5d6 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -222,6 +222,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/atomic-helpers: remove legacy_cursor_update hacks (rev2) 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter ` (6 preceding siblings ...) (?) @ 2022-04-07 12:32 ` Patchwork -1 siblings, 0 replies; 80+ messages in thread From: Patchwork @ 2022-04-07 12:32 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx == Series Details == Series: drm/atomic-helpers: remove legacy_cursor_update hacks (rev2) URL : https://patchwork.freedesktop.org/series/102028/ State : warning == Summary == $ dim checkpatch origin/drm-tip dfd8d6b68c5c drm/atomic-helpers: remove legacy_cursor_update hacks -:29: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates")' #29: commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 -:45: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #45: References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ -:128: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>' total: 1 errors, 2 warnings, 0 checks, 53 lines checked ^ permalink raw reply [flat|nested] 80+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic-helpers: remove legacy_cursor_update hacks (rev2) 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter ` (7 preceding siblings ...) (?) @ 2022-04-07 13:04 ` Patchwork -1 siblings, 0 replies; 80+ messages in thread From: Patchwork @ 2022-04-07 13:04 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 6793 bytes --] == Series Details == Series: drm/atomic-helpers: remove legacy_cursor_update hacks (rev2) URL : https://patchwork.freedesktop.org/series/102028/ State : success == Summary == CI Bug Log - changes from CI_DRM_11471 -> Patchwork_22809 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/index.html Participating hosts (50 -> 46) ------------------------------ Additional (2): bat-hsw-1 fi-tgl-u2 Missing (6): shard-tglu bat-dg1-6 fi-bsw-cyan fi-ctg-p8600 shard-rkl fi-bdw-samus Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_22809: ### IGT changes ### #### Suppressed #### The following results come from untrusted machines, tests, or statuses. They do not affect the overall result. * igt@i915_module_load@reload: - {bat-hsw-1}: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/bat-hsw-1/igt@i915_module_load@reload.html Known issues ------------ Here are the changes found in Patchwork_22809 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@amdgpu/amd_basic@semaphore: - fi-hsw-4770: NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#109315]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-hsw-4770/igt@amdgpu/amd_basic@semaphore.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-tgl-u2/igt@gem_huc_copy@huc-copy.html * igt@kms_busy@basic@flip: - fi-tgl-u2: NOTRUN -> [DMESG-WARN][4] ([i915#402]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-tgl-u2/igt@kms_busy@basic@flip.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-u2: NOTRUN -> [SKIP][5] ([fdo#109284] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-tgl-u2/igt@kms_chamelium@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-u2: NOTRUN -> [SKIP][6] ([i915#4103]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-tgl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-u2: NOTRUN -> [SKIP][7] ([fdo#109285]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-tgl-u2/igt@kms_force_connector_basic@force-load-detect.html * igt@kms_setmode@basic-clone-single-crtc: - fi-tgl-u2: NOTRUN -> [SKIP][8] ([i915#3555]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-tgl-u2/igt@kms_setmode@basic-clone-single-crtc.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][9] ([i915#4312]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-bdw-5557u/igt@runner@aborted.html #### Possible fixes #### * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [INCOMPLETE][10] ([i915#146]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/fi-bdw-5557u/igt@gem_exec_suspend@basic-s3@smem.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-bdw-5557u/igt@gem_exec_suspend@basic-s3@smem.html * igt@i915_selftest@live@gt_heartbeat: - {fi-tgl-dsi}: [DMESG-FAIL][12] -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770: [INCOMPLETE][14] ([i915#4785]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html #### Warnings #### * igt@core_hotunplug@unbind-rebind: - fi-kbl-soraka: [DMESG-WARN][16] ([i915#1982] / [i915#5437]) -> [DMESG-WARN][17] ([i915#5437]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/fi-kbl-soraka/igt@core_hotunplug@unbind-rebind.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/fi-kbl-soraka/igt@core_hotunplug@unbind-rebind.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722 [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785 [i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#5437]: https://gitlab.freedesktop.org/drm/intel/issues/5437 [i915#5535]: https://gitlab.freedesktop.org/drm/intel/issues/5535 Build changes ------------- * Linux: CI_DRM_11471 -> Patchwork_22809 CI-20190529: 20190529 CI_DRM_11471: 7067f6f93e8c8b40c9b4592d7674d0ae0960bab6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6415: c3b690bd5f7fb1fb7ed786ab0f3b815930a6a55f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22809: dfd8d6b68c5cf4035264200fb412d0df9e1716c5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == dfd8d6b68c5c drm/atomic-helpers: remove legacy_cursor_update hacks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/index.html [-- Attachment #2: Type: text/html, Size: 7254 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/atomic-helpers: remove legacy_cursor_update hacks (rev2) 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter ` (8 preceding siblings ...) (?) @ 2022-04-07 18:35 ` Patchwork -1 siblings, 0 replies; 80+ messages in thread From: Patchwork @ 2022-04-07 18:35 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 30284 bytes --] == Series Details == Series: drm/atomic-helpers: remove legacy_cursor_update hacks (rev2) URL : https://patchwork.freedesktop.org/series/102028/ State : success == Summary == CI Bug Log - changes from CI_DRM_11471_full -> Patchwork_22809_full ==================================================== Summary ------- **SUCCESS** No regressions found. Participating hosts (13 -> 12) ------------------------------ Missing (1): shard-dg1 Known issues ------------ Here are the changes found in Patchwork_22809_full that come from known issues: ### CI changes ### #### Issues hit #### * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [FAIL][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4392]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk1/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk2/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk3/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk3/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk4/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk4/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk8/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk8/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk9/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk9/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk9/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk9/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk9/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk8/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk8/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk8/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk7/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk7/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk7/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk6/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk2/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk6/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk6/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk5/boot.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk5/boot.html [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk4/boot.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk4/boot.html [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk3/boot.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk3/boot.html [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk3/boot.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk2/boot.html ### IGT changes ### #### Issues hit #### * igt@gem_exec_capture@pi@vcs0: - shard-skl: NOTRUN -> [INCOMPLETE][51] ([i915#4547]) [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl10/igt@gem_exec_capture@pi@vcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-glk: [PASS][52] -> [FAIL][53] ([i915#2842]) [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk1/igt@gem_exec_fair@basic-pace@rcs0.html [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk3/igt@gem_exec_fair@basic-pace@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][54] -> [FAIL][55] ([i915#2842]) [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-kbl7/igt@gem_exec_fair@basic-pace@vecs0.html [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-kbl1/igt@gem_exec_fair@basic-pace@vecs0.html * igt@gem_exec_flush@basic-uc-ro-default: - shard-snb: [PASS][56] -> [SKIP][57] ([fdo#109271]) [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-snb5/igt@gem_exec_flush@basic-uc-ro-default.html [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-snb6/igt@gem_exec_flush@basic-uc-ro-default.html * igt@gem_lmem_swapping@heavy-multi: - shard-apl: NOTRUN -> [SKIP][58] ([fdo#109271] / [i915#4613]) +1 similar issue [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl4/igt@gem_lmem_swapping@heavy-multi.html * igt@gem_lmem_swapping@heavy-verify-random: - shard-skl: NOTRUN -> [SKIP][59] ([fdo#109271] / [i915#4613]) +3 similar issues [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl6/igt@gem_lmem_swapping@heavy-verify-random.html * igt@gem_pxp@fail-invalid-protected-context: - shard-iclb: NOTRUN -> [SKIP][60] ([i915#4270]) [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@gem_pxp@fail-invalid-protected-context.html * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][61] ([i915#768]) [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][62] -> [FAIL][63] ([i915#454]) [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-iclb5/igt@i915_pm_dc@dc6-dpms.html [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html * igt@i915_pm_lpsp@screens-disabled: - shard-iclb: NOTRUN -> [SKIP][64] ([i915#1902]) [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@i915_pm_lpsp@screens-disabled.html * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-async-flip: - shard-iclb: NOTRUN -> [SKIP][65] ([i915#5286]) +1 similar issue [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip: - shard-apl: NOTRUN -> [SKIP][66] ([fdo#109271] / [i915#3777]) +2 similar issues [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl4/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip.html * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip: - shard-skl: NOTRUN -> [FAIL][67] ([i915#3743]) [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl7/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip: - shard-skl: NOTRUN -> [FAIL][68] ([i915#3763]) [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl6/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip: - shard-skl: NOTRUN -> [SKIP][69] ([fdo#109271] / [i915#3777]) +2 similar issues [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl4/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html * igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][70] ([fdo#109271] / [i915#3886]) +2 similar issues [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl8/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][71] ([fdo#109278] / [i915#3886]) [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc: - shard-skl: NOTRUN -> [SKIP][72] ([fdo#109271] / [i915#3886]) +5 similar issues [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl6/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-d-bad-rotation-90-yf_tiled_ccs: - shard-iclb: NOTRUN -> [SKIP][73] ([fdo#109278]) +4 similar issues [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@kms_ccs@pipe-d-bad-rotation-90-yf_tiled_ccs.html * igt@kms_cdclk@mode-transition: - shard-apl: NOTRUN -> [SKIP][74] ([fdo#109271]) +135 similar issues [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl8/igt@kms_cdclk@mode-transition.html * igt@kms_chamelium@dp-crc-multiple: - shard-apl: NOTRUN -> [SKIP][75] ([fdo#109271] / [fdo#111827]) +9 similar issues [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl6/igt@kms_chamelium@dp-crc-multiple.html * igt@kms_chamelium@hdmi-hpd-storm-disable: - shard-skl: NOTRUN -> [SKIP][76] ([fdo#109271] / [fdo#111827]) +14 similar issues [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl6/igt@kms_chamelium@hdmi-hpd-storm-disable.html * igt@kms_content_protection@atomic: - shard-apl: NOTRUN -> [TIMEOUT][77] ([i915#1319]) [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl4/igt@kms_content_protection@atomic.html * igt@kms_content_protection@mei_interface: - shard-iclb: NOTRUN -> [SKIP][78] ([fdo#109300] / [fdo#111066]) [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@kms_content_protection@mei_interface.html * igt@kms_cursor_crc@pipe-a-cursor-512x512-sliding: - shard-iclb: NOTRUN -> [SKIP][79] ([fdo#109278] / [fdo#109279]) [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@kms_cursor_crc@pipe-a-cursor-512x512-sliding.html * igt@kms_cursor_crc@pipe-b-cursor-32x10-offscreen: - shard-tglb: NOTRUN -> [SKIP][80] ([i915#3359]) [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-tglb3/igt@kms_cursor_crc@pipe-b-cursor-32x10-offscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][81] -> [DMESG-WARN][82] ([i915#180]) +3 similar issues [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-kbl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-kbl4/igt@kms_cursor_crc@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: NOTRUN -> [FAIL][83] ([i915#2346]) [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-iclb: [PASS][84] -> [FAIL][85] ([i915#2346]) [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html * igt@kms_cursor_legacy@flip-vs-cursor-toggle: - shard-skl: [PASS][86] -> [FAIL][87] ([i915#2346]) [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-skl10/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html * igt@kms_cursor_legacy@pipe-d-torture-bo: - shard-skl: NOTRUN -> [SKIP][88] ([fdo#109271] / [i915#533]) [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl10/igt@kms_cursor_legacy@pipe-d-torture-bo.html * igt@kms_draw_crc@draw-method-rgb565-render-4tiled: - shard-iclb: NOTRUN -> [SKIP][89] ([i915#5287]) [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@kms_draw_crc@draw-method-rgb565-render-4tiled.html * igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: - shard-iclb: NOTRUN -> [SKIP][90] ([fdo#109274]) [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@kms_flip@2x-modeset-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-fences-interruptible@b-vga1: - shard-snb: [PASS][91] -> [DMESG-FAIL][92] ([i915#5000]) [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-snb2/igt@kms_flip@flip-vs-fences-interruptible@b-vga1.html [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-snb4/igt@kms_flip@flip-vs-fences-interruptible@b-vga1.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-render: - shard-tglb: NOTRUN -> [SKIP][93] ([fdo#109280] / [fdo#111825]) [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-tglb3/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-render.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-move: - shard-iclb: NOTRUN -> [SKIP][94] ([fdo#109280]) +2 similar issues [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-move.html * igt@kms_hdr@static-swap: - shard-iclb: NOTRUN -> [SKIP][95] ([i915#3555]) [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@kms_hdr@static-swap.html * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-apl: NOTRUN -> [FAIL][96] ([fdo#108145] / [i915#265]) +1 similar issue [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl4/igt@kms_plane_alpha_blend@pipe-b-alpha-7efc.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][97] -> [FAIL][98] ([fdo#108145] / [i915#265]) +2 similar issues [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl1/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max: - shard-skl: NOTRUN -> [FAIL][99] ([fdo#108145] / [i915#265]) +2 similar issues [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max.html * igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-b-edp-1-planes-downscale: - shard-iclb: NOTRUN -> [SKIP][100] ([i915#5235]) +2 similar issues [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-b-edp-1-planes-downscale.html * igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale: - shard-iclb: [PASS][101] -> [SKIP][102] ([i915#5235]) +5 similar issues [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-iclb3/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale.html [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb2/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale.html * igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-a-edp-1-planes-upscale-downscale: - shard-skl: NOTRUN -> [SKIP][103] ([fdo#109271]) +195 similar issues [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl4/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-a-edp-1-planes-upscale-downscale.html * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area: - shard-apl: NOTRUN -> [SKIP][104] ([fdo#109271] / [i915#658]) +1 similar issue [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl8/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area.html * igt@kms_psr2_sf@plane-move-sf-dmg-area: - shard-iclb: NOTRUN -> [SKIP][105] ([fdo#111068] / [i915#658]) [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@kms_psr2_sf@plane-move-sf-dmg-area.html * igt@kms_psr2_su@frontbuffer-xrgb8888: - shard-skl: NOTRUN -> [SKIP][106] ([fdo#109271] / [i915#658]) +1 similar issue [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl6/igt@kms_psr2_su@frontbuffer-xrgb8888.html * igt@kms_psr@psr2_no_drrs: - shard-iclb: [PASS][107] -> [SKIP][108] ([fdo#109441]) +1 similar issue [107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-iclb2/igt@kms_psr@psr2_no_drrs.html [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb1/igt@kms_psr@psr2_no_drrs.html * igt@kms_scaling_modes@scaling-mode-none@edp-1-pipe-c: - shard-iclb: NOTRUN -> [SKIP][109] ([i915#5030]) +2 similar issues [109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@kms_scaling_modes@scaling-mode-none@edp-1-pipe-c.html * igt@kms_vrr@flip-basic: - shard-tglb: NOTRUN -> [SKIP][110] ([fdo#109502]) [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-tglb3/igt@kms_vrr@flip-basic.html * igt@prime_nv_test@i915_nv_sharing: - shard-iclb: NOTRUN -> [SKIP][111] ([fdo#109291]) [111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb8/igt@prime_nv_test@i915_nv_sharing.html * igt@syncobj_timeline@transfer-timeline-point: - shard-apl: NOTRUN -> [DMESG-FAIL][112] ([i915#5098]) [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl1/igt@syncobj_timeline@transfer-timeline-point.html * igt@sysfs_clients@pidname: - shard-skl: NOTRUN -> [SKIP][113] ([fdo#109271] / [i915#2994]) +1 similar issue [113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl7/igt@sysfs_clients@pidname.html * igt@sysfs_clients@split-25: - shard-apl: NOTRUN -> [SKIP][114] ([fdo#109271] / [i915#2994]) +1 similar issue [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl6/igt@sysfs_clients@split-25.html - shard-iclb: NOTRUN -> [SKIP][115] ([i915#2994]) [115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb6/igt@sysfs_clients@split-25.html * igt@sysfs_heartbeat_interval@mixed@vcs0: - shard-skl: [PASS][116] -> [WARN][117] ([i915#4055]) [116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-skl7/igt@sysfs_heartbeat_interval@mixed@vcs0.html [117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl10/igt@sysfs_heartbeat_interval@mixed@vcs0.html * igt@sysfs_heartbeat_interval@mixed@vecs0: - shard-skl: [PASS][118] -> [FAIL][119] ([i915#1731]) [118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-skl7/igt@sysfs_heartbeat_interval@mixed@vecs0.html [119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl10/igt@sysfs_heartbeat_interval@mixed@vecs0.html #### Possible fixes #### * igt@feature_discovery@psr1: - {shard-rkl}: [SKIP][120] ([i915#658]) -> [PASS][121] [120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-2/igt@feature_discovery@psr1.html [121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@feature_discovery@psr1.html * igt@gem_ctx_persistence@engines-cleanup@vecs0: - shard-skl: [DMESG-WARN][122] ([i915#1982]) -> [PASS][123] [122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-skl7/igt@gem_ctx_persistence@engines-cleanup@vecs0.html [123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl10/igt@gem_ctx_persistence@engines-cleanup@vecs0.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [FAIL][124] ([i915#2842]) -> [PASS][125] [124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-tglb7/igt@gem_exec_fair@basic-flow@rcs0.html [125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-tglb8/igt@gem_exec_fair@basic-flow@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [FAIL][126] ([i915#2842]) -> [PASS][127] +1 similar issue [126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-kbl6/igt@gem_exec_fair@basic-none@vcs0.html [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-kbl7/igt@gem_exec_fair@basic-none@vcs0.html * igt@gem_exec_reloc@basic-scanout@vecs0: - {shard-rkl}: [SKIP][128] ([i915#3639]) -> [PASS][129] +3 similar issues [128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-1/igt@gem_exec_reloc@basic-scanout@vecs0.html [129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@gem_exec_reloc@basic-scanout@vecs0.html * igt@gem_exec_whisper@basic-fds-forked: - shard-glk: [DMESG-WARN][130] ([i915#118]) -> [PASS][131] [130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-glk8/igt@gem_exec_whisper@basic-fds-forked.html [131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-glk6/igt@gem_exec_whisper@basic-fds-forked.html * igt@gem_mmap_offset@open-flood: - {shard-rkl}: [INCOMPLETE][132] ([i915#5080]) -> [PASS][133] [132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-5/igt@gem_mmap_offset@open-flood.html [133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-4/igt@gem_mmap_offset@open-flood.html * igt@i915_pm_backlight@fade_with_dpms: - {shard-rkl}: [SKIP][134] ([i915#3012]) -> [PASS][135] [134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-2/igt@i915_pm_backlight@fade_with_dpms.html [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@i915_pm_backlight@fade_with_dpms.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [FAIL][136] ([i915#454]) -> [PASS][137] [136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-iclb8/igt@i915_pm_dc@dc6-psr.html [137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-iclb5/igt@i915_pm_dc@dc6-psr.html * igt@i915_pm_rpm@cursor-dpms: - {shard-rkl}: [SKIP][138] ([i915#1849]) -> [PASS][139] +1 similar issue [138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-1/igt@i915_pm_rpm@cursor-dpms.html [139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@i915_pm_rpm@cursor-dpms.html * igt@i915_pm_rpm@drm-resources-equal: - {shard-rkl}: [SKIP][140] ([fdo#109308]) -> [PASS][141] [140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-4/igt@i915_pm_rpm@drm-resources-equal.html [141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@i915_pm_rpm@drm-resources-equal.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [FAIL][142] ([i915#2521]) -> [PASS][143] [142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip.html [143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-skl3/igt@kms_async_flips@alternate-sync-async-flip.html * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip: - {shard-rkl}: [SKIP][144] ([i915#1845] / [i915#4098]) -> [PASS][145] +26 similar issues [144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html [145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html * igt@kms_color@pipe-a-ctm-0-25: - {shard-rkl}: [SKIP][146] ([i915#1149] / [i915#1849] / [i915#4070] / [i915#4098]) -> [PASS][147] +2 similar issues [146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-2/igt@kms_color@pipe-a-ctm-0-25.html [147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_color@pipe-a-ctm-0-25.html * igt@kms_color@pipe-a-ctm-max: - {shard-rkl}: [SKIP][148] ([i915#1149] / [i915#4070] / [i915#4098]) -> [PASS][149] [148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-4/igt@kms_color@pipe-a-ctm-max.html [149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_color@pipe-a-ctm-max.html * igt@kms_color@pipe-c-invalid-degamma-lut-sizes: - {shard-rkl}: [SKIP][150] ([i915#4070]) -> [PASS][151] +1 similar issue [150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-2/igt@kms_color@pipe-c-invalid-degamma-lut-sizes.html [151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-4/igt@kms_color@pipe-c-invalid-degamma-lut-sizes.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - {shard-rkl}: [SKIP][152] ([fdo#112022] / [i915#4070]) -> [PASS][153] +8 similar issues [152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-2/igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding.html [153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge: - {shard-rkl}: [SKIP][154] ([i915#4070] / [i915#4098]) -> [PASS][155] +2 similar issues [154]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-4/igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge.html [155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic: - {shard-rkl}: [SKIP][156] ([fdo#111825] / [i915#4070]) -> [PASS][157] +3 similar issues [156]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-2/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html [157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html * igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: - {shard-rkl}: [SKIP][158] ([i915#4098] / [i915#4369]) -> [PASS][159] +1 similar issue [158]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-4/igt@kms_draw_crc@draw-method-rgb565-blt-xtiled.html [159]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_draw_crc@draw-method-rgb565-blt-xtiled.html * igt@kms_draw_crc@draw-method-xrgb8888-blt-xtiled: - {shard-rkl}: [SKIP][160] ([fdo#111314] / [i915#4098] / [i915#4369]) -> [PASS][161] +1 similar issue [160]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-rkl-1/igt@kms_draw_crc@draw-method-xrgb8888-blt-xtiled.html [161]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-rkl-6/igt@kms_draw_crc@draw-method-xrgb8888-blt-xtiled.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-apl: [DMESG-WARN][162] ([i915#180]) -> [PASS][163] +5 similar issues [162]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-apl1/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html [163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html * igt@kms_flip@flip-vs-suspend@b-edp1: - shard-skl: [INCOMPLETE][164] ([i915#4839] / [i915#636]) -> [PASS][165] [164]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11471/shard-skl6/igt@k == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22809/index.html [-- Attachment #2: Type: text/html, Size: 33453 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
@ 2023-02-16 11:12 ` Daniel Vetter
0 siblings, 0 replies; 80+ messages in thread
From: Daniel Vetter @ 2023-02-16 11:12 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, Daniel Vetter, Abhinav Kumar,
Thomas Zimmermann, Maxime Ripard, mikita.lipski,
Michel Dänzer, harry.wentland, Rob Clark, Kazlauskas,
Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov,
Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno,
Ville Syrjälä,
Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare,
linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel,
linux-mediatek, Daniel Vetter
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.
For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
Inspired by an amdgpu bug report.
v2: Drop RFC, I think with amdgpu converted over to use
atomic_async_check/commit done in
commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Wed Dec 5 14:59:07 2018 -0500
drm/amd/display: Add fast path for cursor plane updates
we don't have any driver anymore where we have userspace expecting
solid legacy cursor support _and_ they are using the atomic helpers in
their fully glory. So we can retire this.
v3: Paper over msm and i915 regression. The complete_all is the only
thing missing afaict.
v4: Fixup i915 fixup ...
v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in
dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to
untangle this all. Thanks to Abhinav Kumar for the debug help.
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Maxime Ripard <maxime@cerno.tech>
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Cc: Maxime Ripard <maxime@cerno.tech>
Tested-by: Maxime Ripard <maxime@cerno.tech>
Cc: mikita.lipski@amd.com
Cc: Michel Dänzer <michel@daenzer.net>
Cc: harry.wentland@amd.com
Cc: Rob Clark <robdclark@gmail.com>
Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Sean Paul <sean@poorly.run>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -------------
drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++
drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++
3 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index d579fd8f7cb8..f6b4c3a00684 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
int i, ret;
unsigned int crtc_mask = 0;
- /*
- * Legacy cursor ioctls are completely unsynced, and userspace
- * relies on that (by doing tons of cursor updates).
- */
- if (old_state->legacy_cursor_update)
- return;
-
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) {
if (!new_crtc_state->active)
continue;
@@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
continue;
}
- /* Legacy cursor updates are fully unsynced. */
- if (state->legacy_cursor_update) {
- complete_all(&commit->flip_done);
- continue;
- }
-
if (!new_crtc_state->event) {
commit->event = kzalloc(sizeof(*commit->event),
GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 3479125fbda6..2454451fcf95 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref);
return ret;
}
+
+ /*
+ * FIXME: Cut over to (async) commit helpers instead of hand-rolling
+ * everything.
+ */
+ if (state->base.legacy_cursor_update) {
+ struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc *crtc;
+ int i;
+
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
+ complete_all(&new_crtc_state->uapi.commit->flip_done);
+ }
+
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 1686fbb611fd..b7151767b567 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
bool async = kms->funcs->vsync_time &&
can_do_async(state, &async_crtc);
+ /*
+ * FIXME: Convert to async plane helpers and remove the various hacks to
+ * keep the old legacy_cursor_way of doing async commits working for the
+ * dpu code, like the expectation that these don't have a crtc->event.
+ */
+ if (async) {
+ /* both ->event itself and the pointer hold a reference! */
+ drm_crtc_commit_put(async_crtc->state->commit);
+ drm_crtc_commit_put(async_crtc->state->commit);
+ kfree(async_crtc->state->event);
+ async_crtc->state->event = NULL;
+ }
+
trace_msm_atomic_commit_tail_start(async, crtc_mask);
kms->funcs->enable_commit(kms);
@@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
/* async updates are limited to single-crtc updates: */
WARN_ON(crtc_mask != drm_crtc_mask(async_crtc));
+ complete_all(&async_crtc->state->commit->flip_done);
+
/*
* Start timer if we don't already have an update pending
* on this crtc:
--
2.39.0
^ permalink raw reply related [flat|nested] 80+ messages in thread* [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-02-16 11:12 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2023-02-16 11:12 UTC (permalink / raw) To: DRI Development Cc: Intel Graphics Development, Daniel Vetter, Abhinav Kumar, Thomas Zimmermann, Maxime Ripard, mikita.lipski, Michel Dänzer, harry.wentland, Rob Clark, Kazlauskas, Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov, Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno, Ville Syrjälä, Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare, linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Vetter The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit hooks. Support for that for msm and vc4 landed. nouveau and i915 have their own commit routines, doing something similar. For everyone else it's probably better to remove the use-after-free bug, and encourage folks to use the async support instead. The affected drivers which register a legacy cursor plane and don't either use the new async stuff or their own commit routine are: amdgpu, atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. Inspired by an amdgpu bug report. v2: Drop RFC, I think with amdgpu converted over to use atomic_async_check/commit done in commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Date: Wed Dec 5 14:59:07 2018 -0500 drm/amd/display: Add fast path for cursor plane updates we don't have any driver anymore where we have userspace expecting solid legacy cursor support _and_ they are using the atomic helpers in their fully glory. So we can retire this. v3: Paper over msm and i915 regression. The complete_all is the only thing missing afaict. v4: Fixup i915 fixup ... v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to untangle this all. Thanks to Abhinav Kumar for the debug help. Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maxime Ripard <maxime@cerno.tech> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard <maxime@cerno.tech> Tested-by: Maxime Ripard <maxime@cerno.tech> Cc: mikita.lipski@amd.com Cc: Michel Dänzer <michel@daenzer.net> Cc: harry.wentland@amd.com Cc: Rob Clark <robdclark@gmail.com> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Sean Paul <sean@poorly.run> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ 3 files changed, 29 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index d579fd8f7cb8..f6b4c3a00684 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, int i, ret; unsigned int crtc_mask = 0; - /* - * Legacy cursor ioctls are completely unsynced, and userspace - * relies on that (by doing tons of cursor updates). - */ - if (old_state->legacy_cursor_update) - return; - for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { if (!new_crtc_state->active) continue; @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } - /* Legacy cursor updates are fully unsynced. */ - if (state->legacy_cursor_update) { - complete_all(&commit->flip_done); - continue; - } - if (!new_crtc_state->event) { commit->event = kzalloc(sizeof(*commit->event), GFP_KERNEL); diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 3479125fbda6..2454451fcf95 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); return ret; } + + /* + * FIXME: Cut over to (async) commit helpers instead of hand-rolling + * everything. + */ + if (state->base.legacy_cursor_update) { + struct intel_crtc_state *new_crtc_state; + struct intel_crtc *crtc; + int i; + + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) + complete_all(&new_crtc_state->uapi.commit->flip_done); + } + intel_shared_dpll_swap_state(state); intel_atomic_track_fbs(state); diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 1686fbb611fd..b7151767b567 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) bool async = kms->funcs->vsync_time && can_do_async(state, &async_crtc); + /* + * FIXME: Convert to async plane helpers and remove the various hacks to + * keep the old legacy_cursor_way of doing async commits working for the + * dpu code, like the expectation that these don't have a crtc->event. + */ + if (async) { + /* both ->event itself and the pointer hold a reference! */ + drm_crtc_commit_put(async_crtc->state->commit); + drm_crtc_commit_put(async_crtc->state->commit); + kfree(async_crtc->state->event); + async_crtc->state->event = NULL; + } + trace_msm_atomic_commit_tail_start(async, crtc_mask); kms->funcs->enable_commit(kms); @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) /* async updates are limited to single-crtc updates: */ WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); + complete_all(&async_crtc->state->commit->flip_done); + /* * Start timer if we don't already have an update pending * on this crtc: -- 2.39.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 80+ messages in thread
* [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-02-16 11:12 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2023-02-16 11:12 UTC (permalink / raw) To: DRI Development Cc: Daniel Vetter, Daniel Vetter, Dmitry Osipenko, linux-arm-msm, Michel Dänzer, Jani Nikula, Intel Graphics Development, Lucas De Marchi, Abhinav Kumar, linux-mediatek, Maxime Ripard, Matthias Brugger, mikita.lipski, Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno, linux-kernel, Manasi Navare, Thomas Zimmermann, Dmitry Baryshkov, freedreno, Kazlauskas, Nicholas The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit hooks. Support for that for msm and vc4 landed. nouveau and i915 have their own commit routines, doing something similar. For everyone else it's probably better to remove the use-after-free bug, and encourage folks to use the async support instead. The affected drivers which register a legacy cursor plane and don't either use the new async stuff or their own commit routine are: amdgpu, atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. Inspired by an amdgpu bug report. v2: Drop RFC, I think with amdgpu converted over to use atomic_async_check/commit done in commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Date: Wed Dec 5 14:59:07 2018 -0500 drm/amd/display: Add fast path for cursor plane updates we don't have any driver anymore where we have userspace expecting solid legacy cursor support _and_ they are using the atomic helpers in their fully glory. So we can retire this. v3: Paper over msm and i915 regression. The complete_all is the only thing missing afaict. v4: Fixup i915 fixup ... v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to untangle this all. Thanks to Abhinav Kumar for the debug help. Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maxime Ripard <maxime@cerno.tech> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard <maxime@cerno.tech> Tested-by: Maxime Ripard <maxime@cerno.tech> Cc: mikita.lipski@amd.com Cc: Michel Dänzer <michel@daenzer.net> Cc: harry.wentland@amd.com Cc: Rob Clark <robdclark@gmail.com> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Sean Paul <sean@poorly.run> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ 3 files changed, 29 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index d579fd8f7cb8..f6b4c3a00684 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, int i, ret; unsigned int crtc_mask = 0; - /* - * Legacy cursor ioctls are completely unsynced, and userspace - * relies on that (by doing tons of cursor updates). - */ - if (old_state->legacy_cursor_update) - return; - for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { if (!new_crtc_state->active) continue; @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } - /* Legacy cursor updates are fully unsynced. */ - if (state->legacy_cursor_update) { - complete_all(&commit->flip_done); - continue; - } - if (!new_crtc_state->event) { commit->event = kzalloc(sizeof(*commit->event), GFP_KERNEL); diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 3479125fbda6..2454451fcf95 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); return ret; } + + /* + * FIXME: Cut over to (async) commit helpers instead of hand-rolling + * everything. + */ + if (state->base.legacy_cursor_update) { + struct intel_crtc_state *new_crtc_state; + struct intel_crtc *crtc; + int i; + + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) + complete_all(&new_crtc_state->uapi.commit->flip_done); + } + intel_shared_dpll_swap_state(state); intel_atomic_track_fbs(state); diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 1686fbb611fd..b7151767b567 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) bool async = kms->funcs->vsync_time && can_do_async(state, &async_crtc); + /* + * FIXME: Convert to async plane helpers and remove the various hacks to + * keep the old legacy_cursor_way of doing async commits working for the + * dpu code, like the expectation that these don't have a crtc->event. + */ + if (async) { + /* both ->event itself and the pointer hold a reference! */ + drm_crtc_commit_put(async_crtc->state->commit); + drm_crtc_commit_put(async_crtc->state->commit); + kfree(async_crtc->state->event); + async_crtc->state->event = NULL; + } + trace_msm_atomic_commit_tail_start(async, crtc_mask); kms->funcs->enable_commit(kms); @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) /* async updates are limited to single-crtc updates: */ WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); + complete_all(&async_crtc->state->commit->flip_done); + /* * Start timer if we don't already have an update pending * on this crtc: -- 2.39.0 ^ permalink raw reply related [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2023-02-16 11:12 ` Daniel Vetter (?) @ 2023-02-22 23:14 ` Rob Clark -1 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2023-02-22 23:14 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Intel Graphics Development, Abhinav Kumar, Thomas Zimmermann, Maxime Ripard, mikita.lipski, Michel Dänzer, harry.wentland, Kazlauskas, Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov, Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno, Ville Syrjälä, Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare, linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Vetter, Rob Clark On Thu, Feb 16, 2023 at 3:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in > dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to > untangle this all. Thanks to Abhinav Kumar for the debug help. Hmm, are you sure about that double-put? [ +0.501263] ------------[ cut here ]------------ [ +0.000032] refcount_t: underflow; use-after-free. [ +0.000033] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x134 [ +0.000043] Modules linked in: uinput rfcomm algif_hash algif_skcipher af_alg veth venus_dec venus_enc xt_cgroup xt_MASQUERADE qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 qcom_vadc_common cros_ec_typec typec 8021q hci_uart btqca qcom_stats venus_core coresight_etm4x coresight_tmc snd_soc_lpass_sc7180 coresight_replicator coresight_funnel coresight snd_soc_sc7180 ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs bluetooth cros_ec_sensors cfg80211 cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf ecdh_generic ecc cros_ec_sensorhub lzo_rle lzo_compress r8153_ecm cdc_ether usbnet r8152 mii zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev [ +0.000189] CPU: 6 PID: 1854 Comm: DrmThread Not tainted 5.15.93-16271-g5ecce40dbcd4 #46 cf9752a1c9e5b13fd13216094f52d77fa5a5f8f3 [ +0.000016] Hardware name: Google Wormdingler rev1+ INX panel board (DT) [ +0.000008] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.000013] pc : refcount_warn_saturate+0xf8/0x134 [ +0.000011] lr : refcount_warn_saturate+0xf8/0x134 [ +0.000011] sp : ffffffc012e43930 [ +0.000008] x29: ffffffc012e43930 x28: ffffff80d31aa300 x27: 000000000000024e [ +0.000017] x26: 00000000000003bd x25: 0000000000000040 x24: 0000000000000040 [ +0.000014] x23: ffffff8083eb1000 x22: 0000000000000002 x21: ffffff80845bc800 [ +0.000013] x20: 0000000000000040 x19: ffffff80d0cecb00 x18: 0000000060014024 [ +0.000012] x17: 0000000000000000 x16: 000000000000003c x15: ffffffd97e21a1c0 [ +0.000012] x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 [ +0.000014] x11: c0000000ffffdfff x10: ffffffd97f560f50 x9 : 5749cdb403550d00 [ +0.000014] x8 : 5749cdb403550d00 x7 : 0000000000000000 x6 : 372e31332020205b [ +0.000012] x5 : ffffffd97f7b8b24 x4 : 0000000000000000 x3 : ffffffc012e43588 [ +0.000013] x2 : ffffffc012e43590 x1 : 00000000ffffdfff x0 : 0000000000000026 [ +0.000014] Call trace: [ +0.000008] refcount_warn_saturate+0xf8/0x134 [ +0.000013] drm_crtc_commit_put+0x54/0x74 [ +0.000013] __drm_atomic_helper_plane_destroy_state+0x64/0x68 [ +0.000013] dpu_plane_destroy_state+0x24/0x3c [ +0.000017] drm_atomic_state_default_clear+0x13c/0x2d8 [ +0.000015] __drm_atomic_state_free+0x88/0xa0 [ +0.000015] drm_atomic_helper_update_plane+0x158/0x188 [ +0.000014] __setplane_atomic+0xf4/0x138 [ +0.000012] drm_mode_cursor_common+0x2e8/0x40c [ +0.000009] drm_mode_cursor_ioctl+0x48/0x70 [ +0.000008] drm_ioctl_kernel+0xe0/0x158 [ +0.000014] drm_ioctl+0x214/0x480 [ +0.000012] __arm64_sys_ioctl+0x94/0xd4 [ +0.000010] invoke_syscall+0x4c/0x100 [ +0.000013] do_el0_svc+0xa4/0x168 [ +0.000012] el0_svc+0x20/0x50 [ +0.000009] el0t_64_sync_handler+0x20/0x110 [ +0.000008] el0t_64_sync+0x1a4/0x1a8 [ +0.000010] ---[ end trace 35bb2d245a684c9a ]--- BR, -R > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: Maxime Ripard <maxime@cerno.tech> > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Cc: Sean Paul <sean@poorly.run> > Cc: Matthias Brugger <matthias.bgg@gmail.com> > Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > Cc: Jani Nikula <jani.nikula@intel.com> > Cc: Lucas De Marchi <lucas.demarchi@intel.com> > Cc: Imre Deak <imre.deak@intel.com> > Cc: Manasi Navare <manasi.d.navare@intel.com> > Cc: linux-arm-msm@vger.kernel.org > Cc: freedreno@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-mediatek@lists.infradead.org > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ > 3 files changed, 29 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index d579fd8f7cb8..f6b4c3a00684 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index 3479125fbda6..2454451fcf95 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b7151767b567 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > bool async = kms->funcs->vsync_time && > can_do_async(state, &async_crtc); > > + /* > + * FIXME: Convert to async plane helpers and remove the various hacks to > + * keep the old legacy_cursor_way of doing async commits working for the > + * dpu code, like the expectation that these don't have a crtc->event. > + */ > + if (async) { > + /* both ->event itself and the pointer hold a reference! */ > + drm_crtc_commit_put(async_crtc->state->commit); > + drm_crtc_commit_put(async_crtc->state->commit); > + kfree(async_crtc->state->event); > + async_crtc->state->event = NULL; > + } > + > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > kms->funcs->enable_commit(kms); > @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: > -- > 2.39.0 > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-02-22 23:14 ` Rob Clark 0 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2023-02-22 23:14 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Intel Graphics Development, Abhinav Kumar, Thomas Zimmermann, Maxime Ripard, mikita.lipski, Michel Dänzer, harry.wentland, Kazlauskas, Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov, Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno, Ville Syrjälä, Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare, linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Vetter, Rob Clark On Thu, Feb 16, 2023 at 3:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in > dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to > untangle this all. Thanks to Abhinav Kumar for the debug help. Hmm, are you sure about that double-put? [ +0.501263] ------------[ cut here ]------------ [ +0.000032] refcount_t: underflow; use-after-free. [ +0.000033] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x134 [ +0.000043] Modules linked in: uinput rfcomm algif_hash algif_skcipher af_alg veth venus_dec venus_enc xt_cgroup xt_MASQUERADE qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 qcom_vadc_common cros_ec_typec typec 8021q hci_uart btqca qcom_stats venus_core coresight_etm4x coresight_tmc snd_soc_lpass_sc7180 coresight_replicator coresight_funnel coresight snd_soc_sc7180 ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs bluetooth cros_ec_sensors cfg80211 cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf ecdh_generic ecc cros_ec_sensorhub lzo_rle lzo_compress r8153_ecm cdc_ether usbnet r8152 mii zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev [ +0.000189] CPU: 6 PID: 1854 Comm: DrmThread Not tainted 5.15.93-16271-g5ecce40dbcd4 #46 cf9752a1c9e5b13fd13216094f52d77fa5a5f8f3 [ +0.000016] Hardware name: Google Wormdingler rev1+ INX panel board (DT) [ +0.000008] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.000013] pc : refcount_warn_saturate+0xf8/0x134 [ +0.000011] lr : refcount_warn_saturate+0xf8/0x134 [ +0.000011] sp : ffffffc012e43930 [ +0.000008] x29: ffffffc012e43930 x28: ffffff80d31aa300 x27: 000000000000024e [ +0.000017] x26: 00000000000003bd x25: 0000000000000040 x24: 0000000000000040 [ +0.000014] x23: ffffff8083eb1000 x22: 0000000000000002 x21: ffffff80845bc800 [ +0.000013] x20: 0000000000000040 x19: ffffff80d0cecb00 x18: 0000000060014024 [ +0.000012] x17: 0000000000000000 x16: 000000000000003c x15: ffffffd97e21a1c0 [ +0.000012] x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 [ +0.000014] x11: c0000000ffffdfff x10: ffffffd97f560f50 x9 : 5749cdb403550d00 [ +0.000014] x8 : 5749cdb403550d00 x7 : 0000000000000000 x6 : 372e31332020205b [ +0.000012] x5 : ffffffd97f7b8b24 x4 : 0000000000000000 x3 : ffffffc012e43588 [ +0.000013] x2 : ffffffc012e43590 x1 : 00000000ffffdfff x0 : 0000000000000026 [ +0.000014] Call trace: [ +0.000008] refcount_warn_saturate+0xf8/0x134 [ +0.000013] drm_crtc_commit_put+0x54/0x74 [ +0.000013] __drm_atomic_helper_plane_destroy_state+0x64/0x68 [ +0.000013] dpu_plane_destroy_state+0x24/0x3c [ +0.000017] drm_atomic_state_default_clear+0x13c/0x2d8 [ +0.000015] __drm_atomic_state_free+0x88/0xa0 [ +0.000015] drm_atomic_helper_update_plane+0x158/0x188 [ +0.000014] __setplane_atomic+0xf4/0x138 [ +0.000012] drm_mode_cursor_common+0x2e8/0x40c [ +0.000009] drm_mode_cursor_ioctl+0x48/0x70 [ +0.000008] drm_ioctl_kernel+0xe0/0x158 [ +0.000014] drm_ioctl+0x214/0x480 [ +0.000012] __arm64_sys_ioctl+0x94/0xd4 [ +0.000010] invoke_syscall+0x4c/0x100 [ +0.000013] do_el0_svc+0xa4/0x168 [ +0.000012] el0_svc+0x20/0x50 [ +0.000009] el0t_64_sync_handler+0x20/0x110 [ +0.000008] el0t_64_sync+0x1a4/0x1a8 [ +0.000010] ---[ end trace 35bb2d245a684c9a ]--- BR, -R > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: Maxime Ripard <maxime@cerno.tech> > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Cc: Sean Paul <sean@poorly.run> > Cc: Matthias Brugger <matthias.bgg@gmail.com> > Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > Cc: Jani Nikula <jani.nikula@intel.com> > Cc: Lucas De Marchi <lucas.demarchi@intel.com> > Cc: Imre Deak <imre.deak@intel.com> > Cc: Manasi Navare <manasi.d.navare@intel.com> > Cc: linux-arm-msm@vger.kernel.org > Cc: freedreno@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-mediatek@lists.infradead.org > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ > 3 files changed, 29 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index d579fd8f7cb8..f6b4c3a00684 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index 3479125fbda6..2454451fcf95 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b7151767b567 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > bool async = kms->funcs->vsync_time && > can_do_async(state, &async_crtc); > > + /* > + * FIXME: Convert to async plane helpers and remove the various hacks to > + * keep the old legacy_cursor_way of doing async commits working for the > + * dpu code, like the expectation that these don't have a crtc->event. > + */ > + if (async) { > + /* both ->event itself and the pointer hold a reference! */ > + drm_crtc_commit_put(async_crtc->state->commit); > + drm_crtc_commit_put(async_crtc->state->commit); > + kfree(async_crtc->state->event); > + async_crtc->state->event = NULL; > + } > + > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > kms->funcs->enable_commit(kms); > @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: > -- > 2.39.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-02-22 23:14 ` Rob Clark 0 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2023-02-22 23:14 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Daniel Vetter, Rob Clark, Dmitry Osipenko, linux-arm-msm, Michel Dänzer, Jani Nikula, Intel Graphics Development, Lucas De Marchi, Abhinav Kumar, linux-mediatek, Maxime Ripard, Matthias Brugger, mikita.lipski, Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno, linux-kernel, Manasi Navare, Thomas Zimmermann, Dmitry Baryshkov, freedreno, Kazlauskas, Nicholas On Thu, Feb 16, 2023 at 3:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. > > v2: Drop RFC, I think with amdgpu converted over to use > atomic_async_check/commit done in > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Date: Wed Dec 5 14:59:07 2018 -0500 > > drm/amd/display: Add fast path for cursor plane updates > > we don't have any driver anymore where we have userspace expecting > solid legacy cursor support _and_ they are using the atomic helpers in > their fully glory. So we can retire this. > > v3: Paper over msm and i915 regression. The complete_all is the only > thing missing afaict. > > v4: Fixup i915 fixup ... > > v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in > dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to > untangle this all. Thanks to Abhinav Kumar for the debug help. Hmm, are you sure about that double-put? [ +0.501263] ------------[ cut here ]------------ [ +0.000032] refcount_t: underflow; use-after-free. [ +0.000033] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x134 [ +0.000043] Modules linked in: uinput rfcomm algif_hash algif_skcipher af_alg veth venus_dec venus_enc xt_cgroup xt_MASQUERADE qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 qcom_vadc_common cros_ec_typec typec 8021q hci_uart btqca qcom_stats venus_core coresight_etm4x coresight_tmc snd_soc_lpass_sc7180 coresight_replicator coresight_funnel coresight snd_soc_sc7180 ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs bluetooth cros_ec_sensors cfg80211 cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf ecdh_generic ecc cros_ec_sensorhub lzo_rle lzo_compress r8153_ecm cdc_ether usbnet r8152 mii zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev [ +0.000189] CPU: 6 PID: 1854 Comm: DrmThread Not tainted 5.15.93-16271-g5ecce40dbcd4 #46 cf9752a1c9e5b13fd13216094f52d77fa5a5f8f3 [ +0.000016] Hardware name: Google Wormdingler rev1+ INX panel board (DT) [ +0.000008] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.000013] pc : refcount_warn_saturate+0xf8/0x134 [ +0.000011] lr : refcount_warn_saturate+0xf8/0x134 [ +0.000011] sp : ffffffc012e43930 [ +0.000008] x29: ffffffc012e43930 x28: ffffff80d31aa300 x27: 000000000000024e [ +0.000017] x26: 00000000000003bd x25: 0000000000000040 x24: 0000000000000040 [ +0.000014] x23: ffffff8083eb1000 x22: 0000000000000002 x21: ffffff80845bc800 [ +0.000013] x20: 0000000000000040 x19: ffffff80d0cecb00 x18: 0000000060014024 [ +0.000012] x17: 0000000000000000 x16: 000000000000003c x15: ffffffd97e21a1c0 [ +0.000012] x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 [ +0.000014] x11: c0000000ffffdfff x10: ffffffd97f560f50 x9 : 5749cdb403550d00 [ +0.000014] x8 : 5749cdb403550d00 x7 : 0000000000000000 x6 : 372e31332020205b [ +0.000012] x5 : ffffffd97f7b8b24 x4 : 0000000000000000 x3 : ffffffc012e43588 [ +0.000013] x2 : ffffffc012e43590 x1 : 00000000ffffdfff x0 : 0000000000000026 [ +0.000014] Call trace: [ +0.000008] refcount_warn_saturate+0xf8/0x134 [ +0.000013] drm_crtc_commit_put+0x54/0x74 [ +0.000013] __drm_atomic_helper_plane_destroy_state+0x64/0x68 [ +0.000013] dpu_plane_destroy_state+0x24/0x3c [ +0.000017] drm_atomic_state_default_clear+0x13c/0x2d8 [ +0.000015] __drm_atomic_state_free+0x88/0xa0 [ +0.000015] drm_atomic_helper_update_plane+0x158/0x188 [ +0.000014] __setplane_atomic+0xf4/0x138 [ +0.000012] drm_mode_cursor_common+0x2e8/0x40c [ +0.000009] drm_mode_cursor_ioctl+0x48/0x70 [ +0.000008] drm_ioctl_kernel+0xe0/0x158 [ +0.000014] drm_ioctl+0x214/0x480 [ +0.000012] __arm64_sys_ioctl+0x94/0xd4 [ +0.000010] invoke_syscall+0x4c/0x100 [ +0.000013] do_el0_svc+0xa4/0x168 [ +0.000012] el0_svc+0x20/0x50 [ +0.000009] el0t_64_sync_handler+0x20/0x110 [ +0.000008] el0t_64_sync+0x1a4/0x1a8 [ +0.000010] ---[ end trace 35bb2d245a684c9a ]--- BR, -R > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: Maxime Ripard <maxime@cerno.tech> > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard <maxime@cerno.tech> > Tested-by: Maxime Ripard <maxime@cerno.tech> > Cc: mikita.lipski@amd.com > Cc: Michel Dänzer <michel@daenzer.net> > Cc: harry.wentland@amd.com > Cc: Rob Clark <robdclark@gmail.com> > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Cc: Sean Paul <sean@poorly.run> > Cc: Matthias Brugger <matthias.bgg@gmail.com> > Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > Cc: Jani Nikula <jani.nikula@intel.com> > Cc: Lucas De Marchi <lucas.demarchi@intel.com> > Cc: Imre Deak <imre.deak@intel.com> > Cc: Manasi Navare <manasi.d.navare@intel.com> > Cc: linux-arm-msm@vger.kernel.org > Cc: freedreno@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-mediatek@lists.infradead.org > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ > 3 files changed, 29 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index d579fd8f7cb8..f6b4c3a00684 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > int i, ret; > unsigned int crtc_mask = 0; > > - /* > - * Legacy cursor ioctls are completely unsynced, and userspace > - * relies on that (by doing tons of cursor updates). > - */ > - if (old_state->legacy_cursor_update) > - return; > - > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > if (!new_crtc_state->active) > continue; > @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > continue; > } > > - /* Legacy cursor updates are fully unsynced. */ > - if (state->legacy_cursor_update) { > - complete_all(&commit->flip_done); > - continue; > - } > - > if (!new_crtc_state->event) { > commit->event = kzalloc(sizeof(*commit->event), > GFP_KERNEL); > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index 3479125fbda6..2454451fcf95 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > return ret; > } > + > + /* > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > + * everything. > + */ > + if (state->base.legacy_cursor_update) { > + struct intel_crtc_state *new_crtc_state; > + struct intel_crtc *crtc; > + int i; > + > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > + complete_all(&new_crtc_state->uapi.commit->flip_done); > + } > + > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > index 1686fbb611fd..b7151767b567 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > bool async = kms->funcs->vsync_time && > can_do_async(state, &async_crtc); > > + /* > + * FIXME: Convert to async plane helpers and remove the various hacks to > + * keep the old legacy_cursor_way of doing async commits working for the > + * dpu code, like the expectation that these don't have a crtc->event. > + */ > + if (async) { > + /* both ->event itself and the pointer hold a reference! */ > + drm_crtc_commit_put(async_crtc->state->commit); > + drm_crtc_commit_put(async_crtc->state->commit); > + kfree(async_crtc->state->event); > + async_crtc->state->event = NULL; > + } > + > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > kms->funcs->enable_commit(kms); > @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > /* async updates are limited to single-crtc updates: */ > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(&async_crtc->state->commit->flip_done); > + > /* > * Start timer if we don't already have an update pending > * on this crtc: > -- > 2.39.0 > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2023-02-22 23:14 ` Rob Clark (?) @ 2023-02-22 23:21 ` Rob Clark -1 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2023-02-22 23:21 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Intel Graphics Development, Abhinav Kumar, Thomas Zimmermann, Maxime Ripard, mikita.lipski, Michel Dänzer, harry.wentland, Kazlauskas, Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov, Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno, Ville Syrjälä, Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare, linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Vetter, Rob Clark On Wed, Feb 22, 2023 at 3:14 PM Rob Clark <robdclark@gmail.com> wrote: > > On Thu, Feb 16, 2023 at 3:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in > > dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to > > untangle this all. Thanks to Abhinav Kumar for the debug help. > > Hmm, are you sure about that double-put? > > [ +0.501263] ------------[ cut here ]------------ > [ +0.000032] refcount_t: underflow; use-after-free. > [ +0.000033] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 > refcount_warn_saturate+0xf8/0x134 > [ +0.000043] Modules linked in: uinput rfcomm algif_hash > algif_skcipher af_alg veth venus_dec venus_enc xt_cgroup xt_MASQUERADE > qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 qcom_vadc_common > cros_ec_typec typec 8021q hci_uart btqca qcom_stats venus_core > coresight_etm4x coresight_tmc snd_soc_lpass_sc7180 > coresight_replicator coresight_funnel coresight snd_soc_sc7180 > ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs > bluetooth cros_ec_sensors cfg80211 cros_ec_sensors_core > industrialio_triggered_buffer kfifo_buf ecdh_generic ecc > cros_ec_sensorhub lzo_rle lzo_compress r8153_ecm cdc_ether usbnet > r8152 mii zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev > [ +0.000189] CPU: 6 PID: 1854 Comm: DrmThread Not tainted > 5.15.93-16271-g5ecce40dbcd4 #46 > cf9752a1c9e5b13fd13216094f52d77fa5a5f8f3 > [ +0.000016] Hardware name: Google Wormdingler rev1+ INX panel board (DT) > [ +0.000008] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ +0.000013] pc : refcount_warn_saturate+0xf8/0x134 > [ +0.000011] lr : refcount_warn_saturate+0xf8/0x134 > [ +0.000011] sp : ffffffc012e43930 > [ +0.000008] x29: ffffffc012e43930 x28: ffffff80d31aa300 x27: 000000000000024e > [ +0.000017] x26: 00000000000003bd x25: 0000000000000040 x24: 0000000000000040 > [ +0.000014] x23: ffffff8083eb1000 x22: 0000000000000002 x21: ffffff80845bc800 > [ +0.000013] x20: 0000000000000040 x19: ffffff80d0cecb00 x18: 0000000060014024 > [ +0.000012] x17: 0000000000000000 x16: 000000000000003c x15: ffffffd97e21a1c0 > [ +0.000012] x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 > [ +0.000014] x11: c0000000ffffdfff x10: ffffffd97f560f50 x9 : 5749cdb403550d00 > [ +0.000014] x8 : 5749cdb403550d00 x7 : 0000000000000000 x6 : 372e31332020205b > [ +0.000012] x5 : ffffffd97f7b8b24 x4 : 0000000000000000 x3 : ffffffc012e43588 > [ +0.000013] x2 : ffffffc012e43590 x1 : 00000000ffffdfff x0 : 0000000000000026 > [ +0.000014] Call trace: > [ +0.000008] refcount_warn_saturate+0xf8/0x134 > [ +0.000013] drm_crtc_commit_put+0x54/0x74 > [ +0.000013] __drm_atomic_helper_plane_destroy_state+0x64/0x68 > [ +0.000013] dpu_plane_destroy_state+0x24/0x3c > [ +0.000017] drm_atomic_state_default_clear+0x13c/0x2d8 > [ +0.000015] __drm_atomic_state_free+0x88/0xa0 > [ +0.000015] drm_atomic_helper_update_plane+0x158/0x188 > [ +0.000014] __setplane_atomic+0xf4/0x138 > [ +0.000012] drm_mode_cursor_common+0x2e8/0x40c > [ +0.000009] drm_mode_cursor_ioctl+0x48/0x70 > [ +0.000008] drm_ioctl_kernel+0xe0/0x158 > [ +0.000014] drm_ioctl+0x214/0x480 > [ +0.000012] __arm64_sys_ioctl+0x94/0xd4 > [ +0.000010] invoke_syscall+0x4c/0x100 > [ +0.000013] do_el0_svc+0xa4/0x168 > [ +0.000012] el0_svc+0x20/0x50 > [ +0.000009] el0t_64_sync_handler+0x20/0x110 > [ +0.000008] el0t_64_sync+0x1a4/0x1a8 > [ +0.000010] ---[ end trace 35bb2d245a684c9a ]--- > without the double-put it "works" (as in doesn't immediately crash) but we are queuing up a _lot_ of updates (ie. cursor is lagging somewhat behind) BR, -R > > BR, > -R > > > > > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > Cc: Maxime Ripard <maxime@cerno.tech> > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Cc: Sean Paul <sean@poorly.run> > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > > Cc: Jani Nikula <jani.nikula@intel.com> > > Cc: Lucas De Marchi <lucas.demarchi@intel.com> > > Cc: Imre Deak <imre.deak@intel.com> > > Cc: Manasi Navare <manasi.d.navare@intel.com> > > Cc: linux-arm-msm@vger.kernel.org > > Cc: freedreno@lists.freedesktop.org > > Cc: linux-kernel@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-mediatek@lists.infradead.org > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ > > 3 files changed, 29 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index d579fd8f7cb8..f6b4c3a00684 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index 3479125fbda6..2454451fcf95 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b7151767b567 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > bool async = kms->funcs->vsync_time && > > can_do_async(state, &async_crtc); > > > > + /* > > + * FIXME: Convert to async plane helpers and remove the various hacks to > > + * keep the old legacy_cursor_way of doing async commits working for the > > + * dpu code, like the expectation that these don't have a crtc->event. > > + */ > > + if (async) { > > + /* both ->event itself and the pointer hold a reference! */ > > + drm_crtc_commit_put(async_crtc->state->commit); > > + drm_crtc_commit_put(async_crtc->state->commit); > > + kfree(async_crtc->state->event); > > + async_crtc->state->event = NULL; > > + } > > + > > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > > > kms->funcs->enable_commit(kms); > > @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > > 2.39.0 > > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-02-22 23:21 ` Rob Clark 0 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2023-02-22 23:21 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Intel Graphics Development, Abhinav Kumar, Thomas Zimmermann, Maxime Ripard, mikita.lipski, Michel Dänzer, harry.wentland, Kazlauskas, Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov, Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno, Ville Syrjälä, Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare, linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Vetter, Rob Clark On Wed, Feb 22, 2023 at 3:14 PM Rob Clark <robdclark@gmail.com> wrote: > > On Thu, Feb 16, 2023 at 3:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in > > dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to > > untangle this all. Thanks to Abhinav Kumar for the debug help. > > Hmm, are you sure about that double-put? > > [ +0.501263] ------------[ cut here ]------------ > [ +0.000032] refcount_t: underflow; use-after-free. > [ +0.000033] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 > refcount_warn_saturate+0xf8/0x134 > [ +0.000043] Modules linked in: uinput rfcomm algif_hash > algif_skcipher af_alg veth venus_dec venus_enc xt_cgroup xt_MASQUERADE > qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 qcom_vadc_common > cros_ec_typec typec 8021q hci_uart btqca qcom_stats venus_core > coresight_etm4x coresight_tmc snd_soc_lpass_sc7180 > coresight_replicator coresight_funnel coresight snd_soc_sc7180 > ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs > bluetooth cros_ec_sensors cfg80211 cros_ec_sensors_core > industrialio_triggered_buffer kfifo_buf ecdh_generic ecc > cros_ec_sensorhub lzo_rle lzo_compress r8153_ecm cdc_ether usbnet > r8152 mii zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev > [ +0.000189] CPU: 6 PID: 1854 Comm: DrmThread Not tainted > 5.15.93-16271-g5ecce40dbcd4 #46 > cf9752a1c9e5b13fd13216094f52d77fa5a5f8f3 > [ +0.000016] Hardware name: Google Wormdingler rev1+ INX panel board (DT) > [ +0.000008] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ +0.000013] pc : refcount_warn_saturate+0xf8/0x134 > [ +0.000011] lr : refcount_warn_saturate+0xf8/0x134 > [ +0.000011] sp : ffffffc012e43930 > [ +0.000008] x29: ffffffc012e43930 x28: ffffff80d31aa300 x27: 000000000000024e > [ +0.000017] x26: 00000000000003bd x25: 0000000000000040 x24: 0000000000000040 > [ +0.000014] x23: ffffff8083eb1000 x22: 0000000000000002 x21: ffffff80845bc800 > [ +0.000013] x20: 0000000000000040 x19: ffffff80d0cecb00 x18: 0000000060014024 > [ +0.000012] x17: 0000000000000000 x16: 000000000000003c x15: ffffffd97e21a1c0 > [ +0.000012] x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 > [ +0.000014] x11: c0000000ffffdfff x10: ffffffd97f560f50 x9 : 5749cdb403550d00 > [ +0.000014] x8 : 5749cdb403550d00 x7 : 0000000000000000 x6 : 372e31332020205b > [ +0.000012] x5 : ffffffd97f7b8b24 x4 : 0000000000000000 x3 : ffffffc012e43588 > [ +0.000013] x2 : ffffffc012e43590 x1 : 00000000ffffdfff x0 : 0000000000000026 > [ +0.000014] Call trace: > [ +0.000008] refcount_warn_saturate+0xf8/0x134 > [ +0.000013] drm_crtc_commit_put+0x54/0x74 > [ +0.000013] __drm_atomic_helper_plane_destroy_state+0x64/0x68 > [ +0.000013] dpu_plane_destroy_state+0x24/0x3c > [ +0.000017] drm_atomic_state_default_clear+0x13c/0x2d8 > [ +0.000015] __drm_atomic_state_free+0x88/0xa0 > [ +0.000015] drm_atomic_helper_update_plane+0x158/0x188 > [ +0.000014] __setplane_atomic+0xf4/0x138 > [ +0.000012] drm_mode_cursor_common+0x2e8/0x40c > [ +0.000009] drm_mode_cursor_ioctl+0x48/0x70 > [ +0.000008] drm_ioctl_kernel+0xe0/0x158 > [ +0.000014] drm_ioctl+0x214/0x480 > [ +0.000012] __arm64_sys_ioctl+0x94/0xd4 > [ +0.000010] invoke_syscall+0x4c/0x100 > [ +0.000013] do_el0_svc+0xa4/0x168 > [ +0.000012] el0_svc+0x20/0x50 > [ +0.000009] el0t_64_sync_handler+0x20/0x110 > [ +0.000008] el0t_64_sync+0x1a4/0x1a8 > [ +0.000010] ---[ end trace 35bb2d245a684c9a ]--- > without the double-put it "works" (as in doesn't immediately crash) but we are queuing up a _lot_ of updates (ie. cursor is lagging somewhat behind) BR, -R > > BR, > -R > > > > > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > Cc: Maxime Ripard <maxime@cerno.tech> > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Cc: Sean Paul <sean@poorly.run> > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > > Cc: Jani Nikula <jani.nikula@intel.com> > > Cc: Lucas De Marchi <lucas.demarchi@intel.com> > > Cc: Imre Deak <imre.deak@intel.com> > > Cc: Manasi Navare <manasi.d.navare@intel.com> > > Cc: linux-arm-msm@vger.kernel.org > > Cc: freedreno@lists.freedesktop.org > > Cc: linux-kernel@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-mediatek@lists.infradead.org > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ > > 3 files changed, 29 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index d579fd8f7cb8..f6b4c3a00684 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index 3479125fbda6..2454451fcf95 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b7151767b567 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > bool async = kms->funcs->vsync_time && > > can_do_async(state, &async_crtc); > > > > + /* > > + * FIXME: Convert to async plane helpers and remove the various hacks to > > + * keep the old legacy_cursor_way of doing async commits working for the > > + * dpu code, like the expectation that these don't have a crtc->event. > > + */ > > + if (async) { > > + /* both ->event itself and the pointer hold a reference! */ > > + drm_crtc_commit_put(async_crtc->state->commit); > > + drm_crtc_commit_put(async_crtc->state->commit); > > + kfree(async_crtc->state->event); > > + async_crtc->state->event = NULL; > > + } > > + > > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > > > kms->funcs->enable_commit(kms); > > @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > > 2.39.0 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-02-22 23:21 ` Rob Clark 0 siblings, 0 replies; 80+ messages in thread From: Rob Clark @ 2023-02-22 23:21 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Daniel Vetter, Rob Clark, Dmitry Osipenko, linux-arm-msm, Michel Dänzer, Jani Nikula, Intel Graphics Development, Lucas De Marchi, Abhinav Kumar, linux-mediatek, Maxime Ripard, Matthias Brugger, mikita.lipski, Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno, linux-kernel, Manasi Navare, Thomas Zimmermann, Dmitry Baryshkov, freedreno, Kazlauskas, Nicholas On Wed, Feb 22, 2023 at 3:14 PM Rob Clark <robdclark@gmail.com> wrote: > > On Thu, Feb 16, 2023 at 3:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > Inspired by an amdgpu bug report. > > > > v2: Drop RFC, I think with amdgpu converted over to use > > atomic_async_check/commit done in > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > drm/amd/display: Add fast path for cursor plane updates > > > > we don't have any driver anymore where we have userspace expecting > > solid legacy cursor support _and_ they are using the atomic helpers in > > their fully glory. So we can retire this. > > > > v3: Paper over msm and i915 regression. The complete_all is the only > > thing missing afaict. > > > > v4: Fixup i915 fixup ... > > > > v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in > > dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to > > untangle this all. Thanks to Abhinav Kumar for the debug help. > > Hmm, are you sure about that double-put? > > [ +0.501263] ------------[ cut here ]------------ > [ +0.000032] refcount_t: underflow; use-after-free. > [ +0.000033] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 > refcount_warn_saturate+0xf8/0x134 > [ +0.000043] Modules linked in: uinput rfcomm algif_hash > algif_skcipher af_alg veth venus_dec venus_enc xt_cgroup xt_MASQUERADE > qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 qcom_vadc_common > cros_ec_typec typec 8021q hci_uart btqca qcom_stats venus_core > coresight_etm4x coresight_tmc snd_soc_lpass_sc7180 > coresight_replicator coresight_funnel coresight snd_soc_sc7180 > ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs > bluetooth cros_ec_sensors cfg80211 cros_ec_sensors_core > industrialio_triggered_buffer kfifo_buf ecdh_generic ecc > cros_ec_sensorhub lzo_rle lzo_compress r8153_ecm cdc_ether usbnet > r8152 mii zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev > [ +0.000189] CPU: 6 PID: 1854 Comm: DrmThread Not tainted > 5.15.93-16271-g5ecce40dbcd4 #46 > cf9752a1c9e5b13fd13216094f52d77fa5a5f8f3 > [ +0.000016] Hardware name: Google Wormdingler rev1+ INX panel board (DT) > [ +0.000008] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ +0.000013] pc : refcount_warn_saturate+0xf8/0x134 > [ +0.000011] lr : refcount_warn_saturate+0xf8/0x134 > [ +0.000011] sp : ffffffc012e43930 > [ +0.000008] x29: ffffffc012e43930 x28: ffffff80d31aa300 x27: 000000000000024e > [ +0.000017] x26: 00000000000003bd x25: 0000000000000040 x24: 0000000000000040 > [ +0.000014] x23: ffffff8083eb1000 x22: 0000000000000002 x21: ffffff80845bc800 > [ +0.000013] x20: 0000000000000040 x19: ffffff80d0cecb00 x18: 0000000060014024 > [ +0.000012] x17: 0000000000000000 x16: 000000000000003c x15: ffffffd97e21a1c0 > [ +0.000012] x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 > [ +0.000014] x11: c0000000ffffdfff x10: ffffffd97f560f50 x9 : 5749cdb403550d00 > [ +0.000014] x8 : 5749cdb403550d00 x7 : 0000000000000000 x6 : 372e31332020205b > [ +0.000012] x5 : ffffffd97f7b8b24 x4 : 0000000000000000 x3 : ffffffc012e43588 > [ +0.000013] x2 : ffffffc012e43590 x1 : 00000000ffffdfff x0 : 0000000000000026 > [ +0.000014] Call trace: > [ +0.000008] refcount_warn_saturate+0xf8/0x134 > [ +0.000013] drm_crtc_commit_put+0x54/0x74 > [ +0.000013] __drm_atomic_helper_plane_destroy_state+0x64/0x68 > [ +0.000013] dpu_plane_destroy_state+0x24/0x3c > [ +0.000017] drm_atomic_state_default_clear+0x13c/0x2d8 > [ +0.000015] __drm_atomic_state_free+0x88/0xa0 > [ +0.000015] drm_atomic_helper_update_plane+0x158/0x188 > [ +0.000014] __setplane_atomic+0xf4/0x138 > [ +0.000012] drm_mode_cursor_common+0x2e8/0x40c > [ +0.000009] drm_mode_cursor_ioctl+0x48/0x70 > [ +0.000008] drm_ioctl_kernel+0xe0/0x158 > [ +0.000014] drm_ioctl+0x214/0x480 > [ +0.000012] __arm64_sys_ioctl+0x94/0xd4 > [ +0.000010] invoke_syscall+0x4c/0x100 > [ +0.000013] do_el0_svc+0xa4/0x168 > [ +0.000012] el0_svc+0x20/0x50 > [ +0.000009] el0t_64_sync_handler+0x20/0x110 > [ +0.000008] el0t_64_sync+0x1a4/0x1a8 > [ +0.000010] ---[ end trace 35bb2d245a684c9a ]--- > without the double-put it "works" (as in doesn't immediately crash) but we are queuing up a _lot_ of updates (ie. cursor is lagging somewhat behind) BR, -R > > BR, > -R > > > > > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > Cc: Maxime Ripard <maxime@cerno.tech> > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard <maxime@cerno.tech> > > Tested-by: Maxime Ripard <maxime@cerno.tech> > > Cc: mikita.lipski@amd.com > > Cc: Michel Dänzer <michel@daenzer.net> > > Cc: harry.wentland@amd.com > > Cc: Rob Clark <robdclark@gmail.com> > > Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Cc: Sean Paul <sean@poorly.run> > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> > > Cc: Jani Nikula <jani.nikula@intel.com> > > Cc: Lucas De Marchi <lucas.demarchi@intel.com> > > Cc: Imre Deak <imre.deak@intel.com> > > Cc: Manasi Navare <manasi.d.navare@intel.com> > > Cc: linux-arm-msm@vger.kernel.org > > Cc: freedreno@lists.freedesktop.org > > Cc: linux-kernel@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-mediatek@lists.infradead.org > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- > > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/msm/msm_atomic.c | 15 +++++++++++++++ > > 3 files changed, 29 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index d579fd8f7cb8..f6b4c3a00684 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > > int i, ret; > > unsigned int crtc_mask = 0; > > > > - /* > > - * Legacy cursor ioctls are completely unsynced, and userspace > > - * relies on that (by doing tons of cursor updates). > > - */ > > - if (old_state->legacy_cursor_update) > > - return; > > - > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { > > if (!new_crtc_state->active) > > continue; > > @@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > > continue; > > } > > > > - /* Legacy cursor updates are fully unsynced. */ > > - if (state->legacy_cursor_update) { > > - complete_all(&commit->flip_done); > > - continue; > > - } > > - > > if (!new_crtc_state->event) { > > commit->event = kzalloc(sizeof(*commit->event), > > GFP_KERNEL); > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index 3479125fbda6..2454451fcf95 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev, > > intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref); > > return ret; > > } > > + > > + /* > > + * FIXME: Cut over to (async) commit helpers instead of hand-rolling > > + * everything. > > + */ > > + if (state->base.legacy_cursor_update) { > > + struct intel_crtc_state *new_crtc_state; > > + struct intel_crtc *crtc; > > + int i; > > + > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > > + complete_all(&new_crtc_state->uapi.commit->flip_done); > > + } > > + > > intel_shared_dpll_swap_state(state); > > intel_atomic_track_fbs(state); > > > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > > index 1686fbb611fd..b7151767b567 100644 > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > @@ -189,6 +189,19 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > bool async = kms->funcs->vsync_time && > > can_do_async(state, &async_crtc); > > > > + /* > > + * FIXME: Convert to async plane helpers and remove the various hacks to > > + * keep the old legacy_cursor_way of doing async commits working for the > > + * dpu code, like the expectation that these don't have a crtc->event. > > + */ > > + if (async) { > > + /* both ->event itself and the pointer hold a reference! */ > > + drm_crtc_commit_put(async_crtc->state->commit); > > + drm_crtc_commit_put(async_crtc->state->commit); > > + kfree(async_crtc->state->event); > > + async_crtc->state->event = NULL; > > + } > > + > > trace_msm_atomic_commit_tail_start(async, crtc_mask); > > > > kms->funcs->enable_commit(kms); > > @@ -222,6 +235,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) > > /* async updates are limited to single-crtc updates: */ > > WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > > > + complete_all(&async_crtc->state->commit->flip_done); > > + > > /* > > * Start timer if we don't already have an update pending > > * on this crtc: > > -- > > 2.39.0 > > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2023-02-16 11:12 ` Daniel Vetter (?) @ 2023-03-07 14:56 ` Maxime Ripard -1 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2023-03-07 14:56 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Daniel Vetter, Dmitry Osipenko, linux-arm-msm, Intel Graphics Development, Jani Nikula, Michel Dänzer, Lucas De Marchi, Abhinav Kumar, linux-mediatek, Matthias Brugger, mikita.lipski, Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno, linux-kernel, Manasi Navare, Thomas Zimmermann, Dmitry Baryshkov, freedreno, Kazlauskas, Nicholas [-- Attachment #1: Type: text/plain, Size: 1059 bytes --] Hi, On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. Thanks for submitting that patch. It's been in the downstream RPi tree for a while, so I'd really like it to be merged eventually :) Acked-by: Maxime Ripard <maxime@cerno.tech> Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-03-07 14:56 ` Maxime Ripard 0 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2023-03-07 14:56 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Intel Graphics Development, Abhinav Kumar, Thomas Zimmermann, mikita.lipski, Michel Dänzer, harry.wentland, Rob Clark, Kazlauskas, Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov, Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno, Ville Syrjälä, Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare, linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Vetter [-- Attachment #1.1: Type: text/plain, Size: 1059 bytes --] Hi, On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. Thanks for submitting that patch. It's been in the downstream RPi tree for a while, so I'd really like it to be merged eventually :) Acked-by: Maxime Ripard <maxime@cerno.tech> Maxime [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2023-03-07 14:56 ` Maxime Ripard 0 siblings, 0 replies; 80+ messages in thread From: Maxime Ripard @ 2023-03-07 14:56 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Intel Graphics Development, Abhinav Kumar, Thomas Zimmermann, mikita.lipski, Michel Dänzer, harry.wentland, Rob Clark, Kazlauskas, Nicholas, Dmitry Osipenko, Maarten Lankhorst, Dmitry Baryshkov, Sean Paul, Matthias Brugger, AngeloGioacchino Del Regno, Ville Syrjälä, Jani Nikula, Lucas De Marchi, Imre Deak, Manasi Navare, linux-arm-msm, freedreno, linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Vetter [-- Attachment #1: Type: text/plain, Size: 1059 bytes --] Hi, On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > The stuff never really worked, and leads to lots of fun because it > out-of-order frees atomic states. Which upsets KASAN, among other > things. > > For async updates we now have a more solid solution with the > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > for msm and vc4 landed. nouveau and i915 have their own commit > routines, doing something similar. > > For everyone else it's probably better to remove the use-after-free > bug, and encourage folks to use the async support instead. The > affected drivers which register a legacy cursor plane and don't either > use the new async stuff or their own commit routine are: amdgpu, > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > Inspired by an amdgpu bug report. Thanks for submitting that patch. It's been in the downstream RPi tree for a while, so I'd really like it to be merged eventually :) Acked-by: Maxime Ripard <maxime@cerno.tech> Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2023-03-07 14:56 ` Maxime Ripard ` (2 preceding siblings ...) (?) @ 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) -1 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-23 6:09 UTC (permalink / raw) To: maxime, daniel.vetter Cc: manasi.d.navare, linux-mediatek, linux-kernel, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno Hi Maxime, Daniel, We encountered similar issue with mediatek SoCs. We have found that in drm_atomic_helper_commit_rpm(), when disabling the cursor plane, the old_state->legacy_cursor_update in drm_atomic_wait_for_vblank() is set to true. As the result, we are not actually waiting for a vlbank to wait for our hardware to close the cursor plane. Subsequently, the execution proceeds to drm_atomic_helper_cleanup_planes() to free the cursor buffer. This can lead to use-after-free issues with our hardware. Could you please apply this patch to fix our problem? Or are there any considerations for not applying this patch? Regards, Jason-JH.Lin On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't > > either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > vmwgfx. > > > > Inspired by an amdgpu bug report. > > Thanks for submitting that patch. It's been in the downstream RPi > tree > for a while, so I'd really like it to be merged eventually :) > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > Maxime ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-23 6:09 UTC (permalink / raw) To: maxime, daniel.vetter Cc: fshao, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, matthias.bgg, mikita.lipski, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas [-- Attachment #1: Type: text/html, Size: 4092 bytes --] [-- Attachment #2: Type: text/plain, Size: 1854 bytes --] Hi Maxime, Daniel, We encountered similar issue with mediatek SoCs. We have found that in drm_atomic_helper_commit_rpm(), when disabling the cursor plane, the old_state->legacy_cursor_update in drm_atomic_wait_for_vblank() is set to true. As the result, we are not actually waiting for a vlbank to wait for our hardware to close the cursor plane. Subsequently, the execution proceeds to drm_atomic_helper_cleanup_planes() to free the cursor buffer. This can lead to use-after-free issues with our hardware. Could you please apply this patch to fix our problem? Or are there any considerations for not applying this patch? Regards, Jason-JH.Lin On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't > > either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > vmwgfx. > > > > Inspired by an amdgpu bug report. > > Thanks for submitting that patch. It's been in the downstream RPi > tree > for a while, so I'd really like it to be merged eventually :) > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > Maxime ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-23 6:09 UTC (permalink / raw) To: maxime, daniel.vetter Cc: manasi.d.navare, linux-mediatek, linux-kernel, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno Hi Maxime, Daniel, We encountered similar issue with mediatek SoCs. We have found that in drm_atomic_helper_commit_rpm(), when disabling the cursor plane, the old_state->legacy_cursor_update in drm_atomic_wait_for_vblank() is set to true. As the result, we are not actually waiting for a vlbank to wait for our hardware to close the cursor plane. Subsequently, the execution proceeds to drm_atomic_helper_cleanup_planes() to free the cursor buffer. This can lead to use-after-free issues with our hardware. Could you please apply this patch to fix our problem? Or are there any considerations for not applying this patch? Regards, Jason-JH.Lin On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't > > either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > vmwgfx. > > > > Inspired by an amdgpu bug report. > > Thanks for submitting that patch. It's been in the downstream RPi > tree > for a while, so I'd really like it to be merged eventually :) > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-23 6:09 UTC (permalink / raw) To: maxime, daniel.vetter Cc: dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas Hi Maxime, Daniel, We encountered similar issue with mediatek SoCs. We have found that in drm_atomic_helper_commit_rpm(), when disabling the cursor plane, the old_state->legacy_cursor_update in drm_atomic_wait_for_vblank() is set to true. As the result, we are not actually waiting for a vlbank to wait for our hardware to close the cursor plane. Subsequently, the execution proceeds to drm_atomic_helper_cleanup_planes() to free the cursor buffer. This can lead to use-after-free issues with our hardware. Could you please apply this patch to fix our problem? Or are there any considerations for not applying this patch? Regards, Jason-JH.Lin On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't > > either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > vmwgfx. > > > > Inspired by an amdgpu bug report. > > Thanks for submitting that patch. It's been in the downstream RPi > tree > for a while, so I'd really like it to be merged eventually :) > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > Maxime ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-23 6:09 UTC (permalink / raw) To: maxime, daniel.vetter Cc: fshao, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas [-- Attachment #1: Type: text/html, Size: 4092 bytes --] [-- Attachment #2: Type: text/plain, Size: 1854 bytes --] Hi Maxime, Daniel, We encountered similar issue with mediatek SoCs. We have found that in drm_atomic_helper_commit_rpm(), when disabling the cursor plane, the old_state->legacy_cursor_update in drm_atomic_wait_for_vblank() is set to true. As the result, we are not actually waiting for a vlbank to wait for our hardware to close the cursor plane. Subsequently, the execution proceeds to drm_atomic_helper_cleanup_planes() to free the cursor buffer. This can lead to use-after-free issues with our hardware. Could you please apply this patch to fix our problem? Or are there any considerations for not applying this patch? Regards, Jason-JH.Lin On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > The stuff never really worked, and leads to lots of fun because it > > out-of-order frees atomic states. Which upsets KASAN, among other > > things. > > > > For async updates we now have a more solid solution with the > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > that > > for msm and vc4 landed. nouveau and i915 have their own commit > > routines, doing something similar. > > > > For everyone else it's probably better to remove the use-after-free > > bug, and encourage folks to use the async support instead. The > > affected drivers which register a legacy cursor plane and don't > > either > > use the new async stuff or their own commit routine are: amdgpu, > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > vmwgfx. > > > > Inspired by an amdgpu bug report. > > Thanks for submitting that patch. It's been in the downstream RPi > tree > for a while, so I'd really like it to be merged eventually :) > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > Maxime ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) ` (2 preceding siblings ...) (?) @ 2024-01-25 18:17 ` Daniel Vetter -1 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-25 18:17 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, Daniel, > > We encountered similar issue with mediatek SoCs. > > We have found that in drm_atomic_helper_commit_rpm(), when disabling > the cursor plane, the old_state->legacy_cursor_update in > drm_atomic_wait_for_vblank() is set to true. > As the result, we are not actually waiting for a vlbank to wait for our > hardware to close the cursor plane. Subsequently, the execution > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > buffer. This can lead to use-after-free issues with our hardware. > > Could you please apply this patch to fix our problem? > Or are there any considerations for not applying this patch? Mostly it needs someone to collect a pile of acks/tested-by and then land it. I'd be _very_ happy if someone else can take care of that ... There's also the potential issue that it might slow down some of the legacy X11 use-cases that really needed a non-blocking cursor, but I think all the drivers where this matters have switched over to the async plane update stuff meanwhile. So hopefully that's good. Cheers, Sima > > Regards, > Jason-JH.Lin > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > The stuff never really worked, and leads to lots of fun because it > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > things. > > > > > > For async updates we now have a more solid solution with the > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > that > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > routines, doing something similar. > > > > > > For everyone else it's probably better to remove the use-after-free > > > bug, and encourage folks to use the async support instead. The > > > affected drivers which register a legacy cursor plane and don't > > > either > > > use the new async stuff or their own commit routine are: amdgpu, > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > vmwgfx. > > > > > > Inspired by an amdgpu bug report. > > > > Thanks for submitting that patch. It's been in the downstream RPi > > tree > > for a while, so I'd really like it to be merged eventually :) > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-25 18:17 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-25 18:17 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: fshao, daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, Daniel, > > We encountered similar issue with mediatek SoCs. > > We have found that in drm_atomic_helper_commit_rpm(), when disabling > the cursor plane, the old_state->legacy_cursor_update in > drm_atomic_wait_for_vblank() is set to true. > As the result, we are not actually waiting for a vlbank to wait for our > hardware to close the cursor plane. Subsequently, the execution > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > buffer. This can lead to use-after-free issues with our hardware. > > Could you please apply this patch to fix our problem? > Or are there any considerations for not applying this patch? Mostly it needs someone to collect a pile of acks/tested-by and then land it. I'd be _very_ happy if someone else can take care of that ... There's also the potential issue that it might slow down some of the legacy X11 use-cases that really needed a non-blocking cursor, but I think all the drivers where this matters have switched over to the async plane update stuff meanwhile. So hopefully that's good. Cheers, Sima > > Regards, > Jason-JH.Lin > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > The stuff never really worked, and leads to lots of fun because it > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > things. > > > > > > For async updates we now have a more solid solution with the > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > that > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > routines, doing something similar. > > > > > > For everyone else it's probably better to remove the use-after-free > > > bug, and encourage folks to use the async support instead. The > > > affected drivers which register a legacy cursor plane and don't > > > either > > > use the new async stuff or their own commit routine are: amdgpu, > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > vmwgfx. > > > > > > Inspired by an amdgpu bug report. > > > > Thanks for submitting that patch. It's been in the downstream RPi > > tree > > for a while, so I'd really like it to be merged eventually :) > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-25 18:17 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-25 18:17 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: fshao, daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, Daniel, > > We encountered similar issue with mediatek SoCs. > > We have found that in drm_atomic_helper_commit_rpm(), when disabling > the cursor plane, the old_state->legacy_cursor_update in > drm_atomic_wait_for_vblank() is set to true. > As the result, we are not actually waiting for a vlbank to wait for our > hardware to close the cursor plane. Subsequently, the execution > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > buffer. This can lead to use-after-free issues with our hardware. > > Could you please apply this patch to fix our problem? > Or are there any considerations for not applying this patch? Mostly it needs someone to collect a pile of acks/tested-by and then land it. I'd be _very_ happy if someone else can take care of that ... There's also the potential issue that it might slow down some of the legacy X11 use-cases that really needed a non-blocking cursor, but I think all the drivers where this matters have switched over to the async plane update stuff meanwhile. So hopefully that's good. Cheers, Sima > > Regards, > Jason-JH.Lin > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > The stuff never really worked, and leads to lots of fun because it > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > things. > > > > > > For async updates we now have a more solid solution with the > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > that > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > routines, doing something similar. > > > > > > For everyone else it's probably better to remove the use-after-free > > > bug, and encourage folks to use the async support instead. The > > > affected drivers which register a legacy cursor plane and don't > > > either > > > use the new async stuff or their own commit routine are: amdgpu, > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > vmwgfx. > > > > > > Inspired by an amdgpu bug report. > > > > Thanks for submitting that patch. It's been in the downstream RPi > > tree > > for a while, so I'd really like it to be merged eventually :) > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-25 18:17 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-25 18:17 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: maxime, daniel.vetter, manasi.d.navare, linux-mediatek, linux-kernel, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, Daniel, > > We encountered similar issue with mediatek SoCs. > > We have found that in drm_atomic_helper_commit_rpm(), when disabling > the cursor plane, the old_state->legacy_cursor_update in > drm_atomic_wait_for_vblank() is set to true. > As the result, we are not actually waiting for a vlbank to wait for our > hardware to close the cursor plane. Subsequently, the execution > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > buffer. This can lead to use-after-free issues with our hardware. > > Could you please apply this patch to fix our problem? > Or are there any considerations for not applying this patch? Mostly it needs someone to collect a pile of acks/tested-by and then land it. I'd be _very_ happy if someone else can take care of that ... There's also the potential issue that it might slow down some of the legacy X11 use-cases that really needed a non-blocking cursor, but I think all the drivers where this matters have switched over to the async plane update stuff meanwhile. So hopefully that's good. Cheers, Sima > > Regards, > Jason-JH.Lin > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > The stuff never really worked, and leads to lots of fun because it > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > things. > > > > > > For async updates we now have a more solid solution with the > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > that > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > routines, doing something similar. > > > > > > For everyone else it's probably better to remove the use-after-free > > > bug, and encourage folks to use the async support instead. The > > > affected drivers which register a legacy cursor plane and don't > > > either > > > use the new async stuff or their own commit routine are: amdgpu, > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > vmwgfx. > > > > > > Inspired by an amdgpu bug report. > > > > Thanks for submitting that patch. It's been in the downstream RPi > > tree > > for a while, so I'd really like it to be merged eventually :) > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-25 18:17 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-25 18:17 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: maxime, daniel.vetter, manasi.d.navare, linux-mediatek, linux-kernel, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, Daniel, > > We encountered similar issue with mediatek SoCs. > > We have found that in drm_atomic_helper_commit_rpm(), when disabling > the cursor plane, the old_state->legacy_cursor_update in > drm_atomic_wait_for_vblank() is set to true. > As the result, we are not actually waiting for a vlbank to wait for our > hardware to close the cursor plane. Subsequently, the execution > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > buffer. This can lead to use-after-free issues with our hardware. > > Could you please apply this patch to fix our problem? > Or are there any considerations for not applying this patch? Mostly it needs someone to collect a pile of acks/tested-by and then land it. I'd be _very_ happy if someone else can take care of that ... There's also the potential issue that it might slow down some of the legacy X11 use-cases that really needed a non-blocking cursor, but I think all the drivers where this matters have switched over to the async plane update stuff meanwhile. So hopefully that's good. Cheers, Sima > > Regards, > Jason-JH.Lin > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > The stuff never really worked, and leads to lots of fun because it > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > things. > > > > > > For async updates we now have a more solid solution with the > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > that > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > routines, doing something similar. > > > > > > For everyone else it's probably better to remove the use-after-free > > > bug, and encourage folks to use the async support instead. The > > > affected drivers which register a legacy cursor plane and don't > > > either > > > use the new async stuff or their own commit routine are: amdgpu, > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > vmwgfx. > > > > > > Inspired by an amdgpu bug report. > > > > Thanks for submitting that patch. It's been in the downstream RPi > > tree > > for a while, so I'd really like it to be merged eventually :) > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2024-01-25 18:17 ` Daniel Vetter ` (2 preceding siblings ...) (?) @ 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) -1 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-31 5:17 UTC (permalink / raw) To: daniel Cc: linux-kernel, linux-mediatek, daniel.vetter, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > Hi Maxime, Daniel, > > > > We encountered similar issue with mediatek SoCs. > > > > We have found that in drm_atomic_helper_commit_rpm(), when > disabling > > the cursor plane, the old_state->legacy_cursor_update in > > drm_atomic_wait_for_vblank() is set to true. > > As the result, we are not actually waiting for a vlbank to wait for > our > > hardware to close the cursor plane. Subsequently, the execution > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > buffer. This can lead to use-after-free issues with our hardware. > > > > Could you please apply this patch to fix our problem? > > Or are there any considerations for not applying this patch? > > Mostly it needs someone to collect a pile of acks/tested-by and then > land > it. > Got it. I would add tested-by tag for mediatek SoC. > I'd be _very_ happy if someone else can take care of that ... > > There's also the potential issue that it might slow down some of the > legacy X11 use-cases that really needed a non-blocking cursor, but I > think > all the drivers where this matters have switched over to the async > plane > update stuff meanwhile. So hopefully that's good. > I think all the drivers should have switched to async plane update. Can we add the checking condition to see if atomic_async_update/check function are implemented? Regards, Jason-JH.Lin > Cheers, Sima > > > > Regards, > > Jason-JH.Lin > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > The stuff never really worked, and leads to lots of fun because > it > > > > out-of-order frees atomic states. Which upsets KASAN, among > other > > > > things. > > > > > > > > For async updates we now have a more solid solution with the > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > for > > > > that > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > routines, doing something similar. > > > > > > > > For everyone else it's probably better to remove the use-after- > free > > > > bug, and encourage folks to use the async support instead. The > > > > affected drivers which register a legacy cursor plane and don't > > > > either > > > > use the new async stuff or their own commit routine are: > amdgpu, > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > vmwgfx. > > > > > > > > Inspired by an amdgpu bug report. > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > tree > > > for a while, so I'd really like it to be merged eventually :) > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > Maxime > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-31 5:17 UTC (permalink / raw) To: daniel Cc: linux-kernel, linux-mediatek, daniel.vetter, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno [-- Attachment #1: Type: text/html, Size: 6718 bytes --] [-- Attachment #2: Type: text/plain, Size: 3063 bytes --] On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > Hi Maxime, Daniel, > > > > We encountered similar issue with mediatek SoCs. > > > > We have found that in drm_atomic_helper_commit_rpm(), when > disabling > > the cursor plane, the old_state->legacy_cursor_update in > > drm_atomic_wait_for_vblank() is set to true. > > As the result, we are not actually waiting for a vlbank to wait for > our > > hardware to close the cursor plane. Subsequently, the execution > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > buffer. This can lead to use-after-free issues with our hardware. > > > > Could you please apply this patch to fix our problem? > > Or are there any considerations for not applying this patch? > > Mostly it needs someone to collect a pile of acks/tested-by and then > land > it. > Got it. I would add tested-by tag for mediatek SoC. > I'd be _very_ happy if someone else can take care of that ... > > There's also the potential issue that it might slow down some of the > legacy X11 use-cases that really needed a non-blocking cursor, but I > think > all the drivers where this matters have switched over to the async > plane > update stuff meanwhile. So hopefully that's good. > I think all the drivers should have switched to async plane update. Can we add the checking condition to see if atomic_async_update/check function are implemented? Regards, Jason-JH.Lin > Cheers, Sima > > > > Regards, > > Jason-JH.Lin > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > The stuff never really worked, and leads to lots of fun because > it > > > > out-of-order frees atomic states. Which upsets KASAN, among > other > > > > things. > > > > > > > > For async updates we now have a more solid solution with the > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > for > > > > that > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > routines, doing something similar. > > > > > > > > For everyone else it's probably better to remove the use-after- > free > > > > bug, and encourage folks to use the async support instead. The > > > > affected drivers which register a legacy cursor plane and don't > > > > either > > > > use the new async stuff or their own commit routine are: > amdgpu, > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > vmwgfx. > > > > > > > > Inspired by an amdgpu bug report. > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > tree > > > for a while, so I'd really like it to be merged eventually :) > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > Maxime > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-31 5:17 UTC (permalink / raw) To: daniel Cc: linux-kernel, linux-mediatek, daniel.vetter, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > Hi Maxime, Daniel, > > > > We encountered similar issue with mediatek SoCs. > > > > We have found that in drm_atomic_helper_commit_rpm(), when > disabling > > the cursor plane, the old_state->legacy_cursor_update in > > drm_atomic_wait_for_vblank() is set to true. > > As the result, we are not actually waiting for a vlbank to wait for > our > > hardware to close the cursor plane. Subsequently, the execution > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > buffer. This can lead to use-after-free issues with our hardware. > > > > Could you please apply this patch to fix our problem? > > Or are there any considerations for not applying this patch? > > Mostly it needs someone to collect a pile of acks/tested-by and then > land > it. > Got it. I would add tested-by tag for mediatek SoC. > I'd be _very_ happy if someone else can take care of that ... > > There's also the potential issue that it might slow down some of the > legacy X11 use-cases that really needed a non-blocking cursor, but I > think > all the drivers where this matters have switched over to the async > plane > update stuff meanwhile. So hopefully that's good. > I think all the drivers should have switched to async plane update. Can we add the checking condition to see if atomic_async_update/check function are implemented? Regards, Jason-JH.Lin > Cheers, Sima > > > > Regards, > > Jason-JH.Lin > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > The stuff never really worked, and leads to lots of fun because > it > > > > out-of-order frees atomic states. Which upsets KASAN, among > other > > > > things. > > > > > > > > For async updates we now have a more solid solution with the > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > for > > > > that > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > routines, doing something similar. > > > > > > > > For everyone else it's probably better to remove the use-after- > free > > > > bug, and encourage folks to use the async support instead. The > > > > affected drivers which register a legacy cursor plane and don't > > > > either > > > > use the new async stuff or their own commit routine are: > amdgpu, > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > vmwgfx. > > > > > > > > Inspired by an amdgpu bug report. > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > tree > > > for a while, so I'd really like it to be merged eventually :) > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > Maxime > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-31 5:17 UTC (permalink / raw) To: daniel Cc: fshao, daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas [-- Attachment #1: Type: text/html, Size: 6718 bytes --] [-- Attachment #2: Type: text/plain, Size: 3063 bytes --] On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > Hi Maxime, Daniel, > > > > We encountered similar issue with mediatek SoCs. > > > > We have found that in drm_atomic_helper_commit_rpm(), when > disabling > > the cursor plane, the old_state->legacy_cursor_update in > > drm_atomic_wait_for_vblank() is set to true. > > As the result, we are not actually waiting for a vlbank to wait for > our > > hardware to close the cursor plane. Subsequently, the execution > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > buffer. This can lead to use-after-free issues with our hardware. > > > > Could you please apply this patch to fix our problem? > > Or are there any considerations for not applying this patch? > > Mostly it needs someone to collect a pile of acks/tested-by and then > land > it. > Got it. I would add tested-by tag for mediatek SoC. > I'd be _very_ happy if someone else can take care of that ... > > There's also the potential issue that it might slow down some of the > legacy X11 use-cases that really needed a non-blocking cursor, but I > think > all the drivers where this matters have switched over to the async > plane > update stuff meanwhile. So hopefully that's good. > I think all the drivers should have switched to async plane update. Can we add the checking condition to see if atomic_async_update/check function are implemented? Regards, Jason-JH.Lin > Cheers, Sima > > > > Regards, > > Jason-JH.Lin > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > The stuff never really worked, and leads to lots of fun because > it > > > > out-of-order frees atomic states. Which upsets KASAN, among > other > > > > things. > > > > > > > > For async updates we now have a more solid solution with the > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > for > > > > that > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > routines, doing something similar. > > > > > > > > For everyone else it's probably better to remove the use-after- > free > > > > bug, and encourage folks to use the async support instead. The > > > > affected drivers which register a legacy cursor plane and don't > > > > either > > > > use the new async stuff or their own commit routine are: > amdgpu, > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > vmwgfx. > > > > > > > > Inspired by an amdgpu bug report. > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > tree > > > for a while, so I'd really like it to be merged eventually :) > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > Maxime > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 0 siblings, 0 replies; 80+ messages in thread From: Jason-JH Lin (林睿祥) @ 2024-01-31 5:17 UTC (permalink / raw) To: daniel Cc: daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > Hi Maxime, Daniel, > > > > We encountered similar issue with mediatek SoCs. > > > > We have found that in drm_atomic_helper_commit_rpm(), when > disabling > > the cursor plane, the old_state->legacy_cursor_update in > > drm_atomic_wait_for_vblank() is set to true. > > As the result, we are not actually waiting for a vlbank to wait for > our > > hardware to close the cursor plane. Subsequently, the execution > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > buffer. This can lead to use-after-free issues with our hardware. > > > > Could you please apply this patch to fix our problem? > > Or are there any considerations for not applying this patch? > > Mostly it needs someone to collect a pile of acks/tested-by and then > land > it. > Got it. I would add tested-by tag for mediatek SoC. > I'd be _very_ happy if someone else can take care of that ... > > There's also the potential issue that it might slow down some of the > legacy X11 use-cases that really needed a non-blocking cursor, but I > think > all the drivers where this matters have switched over to the async > plane > update stuff meanwhile. So hopefully that's good. > I think all the drivers should have switched to async plane update. Can we add the checking condition to see if atomic_async_update/check function are implemented? Regards, Jason-JH.Lin > Cheers, Sima > > > > Regards, > > Jason-JH.Lin > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > The stuff never really worked, and leads to lots of fun because > it > > > > out-of-order frees atomic states. Which upsets KASAN, among > other > > > > things. > > > > > > > > For async updates we now have a more solid solution with the > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > for > > > > that > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > routines, doing something similar. > > > > > > > > For everyone else it's probably better to remove the use-after- > free > > > > bug, and encourage folks to use the async support instead. The > > > > affected drivers which register a legacy cursor plane and don't > > > > either > > > > use the new async stuff or their own commit routine are: > amdgpu, > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > vmwgfx. > > > > > > > > Inspired by an amdgpu bug report. > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > tree > > > for a while, so I'd really like it to be merged eventually :) > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > Maxime > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) ` (2 preceding siblings ...) (?) @ 2024-01-31 9:11 ` Daniel Vetter -1 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 9:11 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: daniel, linux-kernel, linux-mediatek, daniel.vetter, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > Hi Maxime, Daniel, > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > disabling > > > the cursor plane, the old_state->legacy_cursor_update in > > > drm_atomic_wait_for_vblank() is set to true. > > > As the result, we are not actually waiting for a vlbank to wait for > > our > > > hardware to close the cursor plane. Subsequently, the execution > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > Could you please apply this patch to fix our problem? > > > Or are there any considerations for not applying this patch? > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > land > > it. > > > > Got it. I would add tested-by tag for mediatek SoC. > > > I'd be _very_ happy if someone else can take care of that ... > > > > There's also the potential issue that it might slow down some of the > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > think > > all the drivers where this matters have switched over to the async > > plane > > update stuff meanwhile. So hopefully that's good. > > > > I think all the drivers should have switched to async plane update. > > Can we add the checking condition to see if atomic_async_update/check > function are implemented? Pretty sure not all have done that, so really it boils down to whether we break a real user's use-case. Which pretty much can only be checked by merging the patch (hence the requirement to get as many acks as possible from display drivers) and then being willing to handle any fallout that's reported as regressions for a specific driver. It's a pile of work, at least when it goes south, that's why I'm looking for volunteers. Note that handling the fallout doesn't mean you have to fix that specific driver, the only realistic option might be to reinstate the legacy cursor behaviour, but as an explicit opt-in that only that specific driver enables. So maybe for next round of that patch it might be good to have a 2nd patch which implements this fallback plan in the shared atomic modeset code? Cheers, Sima > > Regards, > Jason-JH.Lin > > > Cheers, Sima > > > > > > Regards, > > > Jason-JH.Lin > > > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > > The stuff never really worked, and leads to lots of fun because > > it > > > > > out-of-order frees atomic states. Which upsets KASAN, among > > other > > > > > things. > > > > > > > > > > For async updates we now have a more solid solution with the > > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > > for > > > > > that > > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > > routines, doing something similar. > > > > > > > > > > For everyone else it's probably better to remove the use-after- > > free > > > > > bug, and encourage folks to use the async support instead. The > > > > > affected drivers which register a legacy cursor plane and don't > > > > > either > > > > > use the new async stuff or their own commit routine are: > > amdgpu, > > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > > vmwgfx. > > > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > > tree > > > > for a while, so I'd really like it to be merged eventually :) > > > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > > > Maxime > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 9:11 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 9:11 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: daniel, linux-kernel, linux-mediatek, daniel.vetter, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > Hi Maxime, Daniel, > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > disabling > > > the cursor plane, the old_state->legacy_cursor_update in > > > drm_atomic_wait_for_vblank() is set to true. > > > As the result, we are not actually waiting for a vlbank to wait for > > our > > > hardware to close the cursor plane. Subsequently, the execution > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > Could you please apply this patch to fix our problem? > > > Or are there any considerations for not applying this patch? > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > land > > it. > > > > Got it. I would add tested-by tag for mediatek SoC. > > > I'd be _very_ happy if someone else can take care of that ... > > > > There's also the potential issue that it might slow down some of the > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > think > > all the drivers where this matters have switched over to the async > > plane > > update stuff meanwhile. So hopefully that's good. > > > > I think all the drivers should have switched to async plane update. > > Can we add the checking condition to see if atomic_async_update/check > function are implemented? Pretty sure not all have done that, so really it boils down to whether we break a real user's use-case. Which pretty much can only be checked by merging the patch (hence the requirement to get as many acks as possible from display drivers) and then being willing to handle any fallout that's reported as regressions for a specific driver. It's a pile of work, at least when it goes south, that's why I'm looking for volunteers. Note that handling the fallout doesn't mean you have to fix that specific driver, the only realistic option might be to reinstate the legacy cursor behaviour, but as an explicit opt-in that only that specific driver enables. So maybe for next round of that patch it might be good to have a 2nd patch which implements this fallback plan in the shared atomic modeset code? Cheers, Sima > > Regards, > Jason-JH.Lin > > > Cheers, Sima > > > > > > Regards, > > > Jason-JH.Lin > > > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > > The stuff never really worked, and leads to lots of fun because > > it > > > > > out-of-order frees atomic states. Which upsets KASAN, among > > other > > > > > things. > > > > > > > > > > For async updates we now have a more solid solution with the > > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > > for > > > > > that > > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > > routines, doing something similar. > > > > > > > > > > For everyone else it's probably better to remove the use-after- > > free > > > > > bug, and encourage folks to use the async support instead. The > > > > > affected drivers which register a legacy cursor plane and don't > > > > > either > > > > > use the new async stuff or their own commit routine are: > > amdgpu, > > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > > vmwgfx. > > > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > > tree > > > > for a while, so I'd really like it to be merged eventually :) > > > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > > > Maxime > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 9:11 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 9:11 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: fshao, daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, daniel, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > Hi Maxime, Daniel, > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > disabling > > > the cursor plane, the old_state->legacy_cursor_update in > > > drm_atomic_wait_for_vblank() is set to true. > > > As the result, we are not actually waiting for a vlbank to wait for > > our > > > hardware to close the cursor plane. Subsequently, the execution > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > Could you please apply this patch to fix our problem? > > > Or are there any considerations for not applying this patch? > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > land > > it. > > > > Got it. I would add tested-by tag for mediatek SoC. > > > I'd be _very_ happy if someone else can take care of that ... > > > > There's also the potential issue that it might slow down some of the > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > think > > all the drivers where this matters have switched over to the async > > plane > > update stuff meanwhile. So hopefully that's good. > > > > I think all the drivers should have switched to async plane update. > > Can we add the checking condition to see if atomic_async_update/check > function are implemented? Pretty sure not all have done that, so really it boils down to whether we break a real user's use-case. Which pretty much can only be checked by merging the patch (hence the requirement to get as many acks as possible from display drivers) and then being willing to handle any fallout that's reported as regressions for a specific driver. It's a pile of work, at least when it goes south, that's why I'm looking for volunteers. Note that handling the fallout doesn't mean you have to fix that specific driver, the only realistic option might be to reinstate the legacy cursor behaviour, but as an explicit opt-in that only that specific driver enables. So maybe for next round of that patch it might be good to have a 2nd patch which implements this fallback plan in the shared atomic modeset code? Cheers, Sima > > Regards, > Jason-JH.Lin > > > Cheers, Sima > > > > > > Regards, > > > Jason-JH.Lin > > > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > > The stuff never really worked, and leads to lots of fun because > > it > > > > > out-of-order frees atomic states. Which upsets KASAN, among > > other > > > > > things. > > > > > > > > > > For async updates we now have a more solid solution with the > > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > > for > > > > > that > > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > > routines, doing something similar. > > > > > > > > > > For everyone else it's probably better to remove the use-after- > > free > > > > > bug, and encourage folks to use the async support instead. The > > > > > affected drivers which register a legacy cursor plane and don't > > > > > either > > > > > use the new async stuff or their own commit routine are: > > amdgpu, > > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > > vmwgfx. > > > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > > tree > > > > for a while, so I'd really like it to be merged eventually :) > > > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > > > Maxime > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 9:11 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 9:11 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: fshao, daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, daniel, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > Hi Maxime, Daniel, > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > disabling > > > the cursor plane, the old_state->legacy_cursor_update in > > > drm_atomic_wait_for_vblank() is set to true. > > > As the result, we are not actually waiting for a vlbank to wait for > > our > > > hardware to close the cursor plane. Subsequently, the execution > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > Could you please apply this patch to fix our problem? > > > Or are there any considerations for not applying this patch? > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > land > > it. > > > > Got it. I would add tested-by tag for mediatek SoC. > > > I'd be _very_ happy if someone else can take care of that ... > > > > There's also the potential issue that it might slow down some of the > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > think > > all the drivers where this matters have switched over to the async > > plane > > update stuff meanwhile. So hopefully that's good. > > > > I think all the drivers should have switched to async plane update. > > Can we add the checking condition to see if atomic_async_update/check > function are implemented? Pretty sure not all have done that, so really it boils down to whether we break a real user's use-case. Which pretty much can only be checked by merging the patch (hence the requirement to get as many acks as possible from display drivers) and then being willing to handle any fallout that's reported as regressions for a specific driver. It's a pile of work, at least when it goes south, that's why I'm looking for volunteers. Note that handling the fallout doesn't mean you have to fix that specific driver, the only realistic option might be to reinstate the legacy cursor behaviour, but as an explicit opt-in that only that specific driver enables. So maybe for next round of that patch it might be good to have a 2nd patch which implements this fallback plan in the shared atomic modeset code? Cheers, Sima > > Regards, > Jason-JH.Lin > > > Cheers, Sima > > > > > > Regards, > > > Jason-JH.Lin > > > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > > The stuff never really worked, and leads to lots of fun because > > it > > > > > out-of-order frees atomic states. Which upsets KASAN, among > > other > > > > > things. > > > > > > > > > > For async updates we now have a more solid solution with the > > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > > for > > > > > that > > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > > routines, doing something similar. > > > > > > > > > > For everyone else it's probably better to remove the use-after- > > free > > > > > bug, and encourage folks to use the async support instead. The > > > > > affected drivers which register a legacy cursor plane and don't > > > > > either > > > > > use the new async stuff or their own commit routine are: > > amdgpu, > > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > > vmwgfx. > > > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > > tree > > > > for a while, so I'd really like it to be merged eventually :) > > > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > > > Maxime > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 9:11 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 9:11 UTC (permalink / raw) To: Jason-JH Lin (林睿祥) Cc: daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, daniel, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, linux-kernel, manasi.d.navare, tzimmermann, dmitry.baryshkov, freedreno, nicholas.kazlauskas On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > Hi Maxime, Daniel, > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > disabling > > > the cursor plane, the old_state->legacy_cursor_update in > > > drm_atomic_wait_for_vblank() is set to true. > > > As the result, we are not actually waiting for a vlbank to wait for > > our > > > hardware to close the cursor plane. Subsequently, the execution > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > Could you please apply this patch to fix our problem? > > > Or are there any considerations for not applying this patch? > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > land > > it. > > > > Got it. I would add tested-by tag for mediatek SoC. > > > I'd be _very_ happy if someone else can take care of that ... > > > > There's also the potential issue that it might slow down some of the > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > think > > all the drivers where this matters have switched over to the async > > plane > > update stuff meanwhile. So hopefully that's good. > > > > I think all the drivers should have switched to async plane update. > > Can we add the checking condition to see if atomic_async_update/check > function are implemented? Pretty sure not all have done that, so really it boils down to whether we break a real user's use-case. Which pretty much can only be checked by merging the patch (hence the requirement to get as many acks as possible from display drivers) and then being willing to handle any fallout that's reported as regressions for a specific driver. It's a pile of work, at least when it goes south, that's why I'm looking for volunteers. Note that handling the fallout doesn't mean you have to fix that specific driver, the only realistic option might be to reinstate the legacy cursor behaviour, but as an explicit opt-in that only that specific driver enables. So maybe for next round of that patch it might be good to have a 2nd patch which implements this fallback plan in the shared atomic modeset code? Cheers, Sima > > Regards, > Jason-JH.Lin > > > Cheers, Sima > > > > > > Regards, > > > Jason-JH.Lin > > > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > > The stuff never really worked, and leads to lots of fun because > > it > > > > > out-of-order frees atomic states. Which upsets KASAN, among > > other > > > > > things. > > > > > > > > > > For async updates we now have a more solid solution with the > > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > > for > > > > > that > > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > > routines, doing something similar. > > > > > > > > > > For everyone else it's probably better to remove the use-after- > > free > > > > > bug, and encourage folks to use the async support instead. The > > > > > affected drivers which register a legacy cursor plane and don't > > > > > either > > > > > use the new async stuff or their own commit routine are: > > amdgpu, > > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > > vmwgfx. > > > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > > tree > > > > for a while, so I'd really like it to be merged eventually :) > > > > > > > > Acked-by: Maxime Ripard <maxime@cerno.tech> > > > > > > > > Maxime > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2024-01-31 9:11 ` Daniel Vetter (?) @ 2024-01-31 10:26 ` Dmitry Baryshkov -1 siblings, 0 replies; 80+ messages in thread From: Dmitry Baryshkov @ 2024-01-31 10:26 UTC (permalink / raw) To: Jason-JH Lin (林睿祥), linux-kernel, linux-mediatek, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno Cc: daniel, daniel.vetter On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > External email : Please do not click links or open attachments until > > > you have verified the sender or the content. > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > Hi Maxime, Daniel, > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > disabling > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > drm_atomic_wait_for_vblank() is set to true. > > > > As the result, we are not actually waiting for a vlbank to wait for > > > our > > > > hardware to close the cursor plane. Subsequently, the execution > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > Could you please apply this patch to fix our problem? > > > > Or are there any considerations for not applying this patch? > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > land > > > it. > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > There's also the potential issue that it might slow down some of the > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > think > > > all the drivers where this matters have switched over to the async > > > plane > > > update stuff meanwhile. So hopefully that's good. > > > > > > > I think all the drivers should have switched to async plane update. > > > > Can we add the checking condition to see if atomic_async_update/check > > function are implemented? > > Pretty sure not all have done that, so really it boils down to whether we > break a real user's use-case. Which pretty much can only be checked by > merging the patch (hence the requirement to get as many acks as possible > from display drivers) and then being willing to handle any fallout that's > reported as regressions for a specific driver. > > It's a pile of work, at least when it goes south, that's why I'm looking > for volunteers. I can check this on all sensible msm generations, including mdp4, but it will be next week, after the FOSDEM. BTW, for technical reasons one of the msm platforms still has the legacy cursor implementation might it be related? > > Note that handling the fallout doesn't mean you have to fix that specific > driver, the only realistic option might be to reinstate the legacy cursor > behaviour, but as an explicit opt-in that only that specific driver > enables. > > So maybe for next round of that patch it might be good to have a 2nd patch > which implements this fallback plan in the shared atomic modeset code? > > Cheers, Sima -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 10:26 ` Dmitry Baryshkov 0 siblings, 0 replies; 80+ messages in thread From: Dmitry Baryshkov @ 2024-01-31 10:26 UTC (permalink / raw) To: Jason-JH Lin (林睿祥), linux-kernel, linux-mediatek, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno Cc: daniel.vetter, daniel On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > External email : Please do not click links or open attachments until > > > you have verified the sender or the content. > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > Hi Maxime, Daniel, > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > disabling > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > drm_atomic_wait_for_vblank() is set to true. > > > > As the result, we are not actually waiting for a vlbank to wait for > > > our > > > > hardware to close the cursor plane. Subsequently, the execution > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > Could you please apply this patch to fix our problem? > > > > Or are there any considerations for not applying this patch? > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > land > > > it. > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > There's also the potential issue that it might slow down some of the > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > think > > > all the drivers where this matters have switched over to the async > > > plane > > > update stuff meanwhile. So hopefully that's good. > > > > > > > I think all the drivers should have switched to async plane update. > > > > Can we add the checking condition to see if atomic_async_update/check > > function are implemented? > > Pretty sure not all have done that, so really it boils down to whether we > break a real user's use-case. Which pretty much can only be checked by > merging the patch (hence the requirement to get as many acks as possible > from display drivers) and then being willing to handle any fallout that's > reported as regressions for a specific driver. > > It's a pile of work, at least when it goes south, that's why I'm looking > for volunteers. I can check this on all sensible msm generations, including mdp4, but it will be next week, after the FOSDEM. BTW, for technical reasons one of the msm platforms still has the legacy cursor implementation might it be related? > > Note that handling the fallout doesn't mean you have to fix that specific > driver, the only realistic option might be to reinstate the legacy cursor > behaviour, but as an explicit opt-in that only that specific driver > enables. > > So maybe for next round of that patch it might be good to have a 2nd patch > which implements this fallback plan in the shared atomic modeset code? > > Cheers, Sima -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 10:26 ` Dmitry Baryshkov 0 siblings, 0 replies; 80+ messages in thread From: Dmitry Baryshkov @ 2024-01-31 10:26 UTC (permalink / raw) To: Jason-JH Lin (林睿祥), linux-kernel, linux-mediatek, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, dmitry.baryshkov, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno Cc: daniel, daniel.vetter On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > External email : Please do not click links or open attachments until > > > you have verified the sender or the content. > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > Hi Maxime, Daniel, > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > disabling > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > drm_atomic_wait_for_vblank() is set to true. > > > > As the result, we are not actually waiting for a vlbank to wait for > > > our > > > > hardware to close the cursor plane. Subsequently, the execution > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > Could you please apply this patch to fix our problem? > > > > Or are there any considerations for not applying this patch? > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > land > > > it. > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > There's also the potential issue that it might slow down some of the > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > think > > > all the drivers where this matters have switched over to the async > > > plane > > > update stuff meanwhile. So hopefully that's good. > > > > > > > I think all the drivers should have switched to async plane update. > > > > Can we add the checking condition to see if atomic_async_update/check > > function are implemented? > > Pretty sure not all have done that, so really it boils down to whether we > break a real user's use-case. Which pretty much can only be checked by > merging the patch (hence the requirement to get as many acks as possible > from display drivers) and then being willing to handle any fallout that's > reported as regressions for a specific driver. > > It's a pile of work, at least when it goes south, that's why I'm looking > for volunteers. I can check this on all sensible msm generations, including mdp4, but it will be next week, after the FOSDEM. BTW, for technical reasons one of the msm platforms still has the legacy cursor implementation might it be related? > > Note that handling the fallout doesn't mean you have to fix that specific > driver, the only realistic option might be to reinstate the legacy cursor > behaviour, but as an explicit opt-in that only that specific driver > enables. > > So maybe for next round of that patch it might be good to have a 2nd patch > which implements this fallback plan in the shared atomic modeset code? > > Cheers, Sima -- With best wishes Dmitry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2024-01-31 10:26 ` Dmitry Baryshkov ` (2 preceding siblings ...) (?) @ 2024-01-31 11:28 ` Daniel Vetter -1 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 11:28 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Jason-JH Lin (林睿祥), linux-kernel, linux-mediatek, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno, daniel, daniel.vetter On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote: > On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > > > External email : Please do not click links or open attachments until > > > > you have verified the sender or the content. > > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > > Hi Maxime, Daniel, > > > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > > disabling > > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > > drm_atomic_wait_for_vblank() is set to true. > > > > > As the result, we are not actually waiting for a vlbank to wait for > > > > our > > > > > hardware to close the cursor plane. Subsequently, the execution > > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > > > Could you please apply this patch to fix our problem? > > > > > Or are there any considerations for not applying this patch? > > > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > > land > > > > it. > > > > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > > > There's also the potential issue that it might slow down some of the > > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > > think > > > > all the drivers where this matters have switched over to the async > > > > plane > > > > update stuff meanwhile. So hopefully that's good. > > > > > > > > > > I think all the drivers should have switched to async plane update. > > > > > > Can we add the checking condition to see if atomic_async_update/check > > > function are implemented? > > > > Pretty sure not all have done that, so really it boils down to whether we > > break a real user's use-case. Which pretty much can only be checked by > > merging the patch (hence the requirement to get as many acks as possible > > from display drivers) and then being willing to handle any fallout that's > > reported as regressions for a specific driver. > > > > It's a pile of work, at least when it goes south, that's why I'm looking > > for volunteers. > > I can check this on all sensible msm generations, including mdp4, but > it will be next week, after the FOSDEM. > > BTW, for technical reasons one of the msm platforms still has the > legacy cursor implementation might it be related? Yeah, msm is one of the drivers I had to change with some hacks to avoid really bad fallout. It should still work like before, but that's one that definitely needs testing. -Sima > > > > > Note that handling the fallout doesn't mean you have to fix that specific > > driver, the only realistic option might be to reinstate the legacy cursor > > behaviour, but as an explicit opt-in that only that specific driver > > enables. > > > > So maybe for next round of that patch it might be good to have a 2nd patch > > which implements this fallback plan in the shared atomic modeset code? > > > > Cheers, Sima > > > -- > With best wishes > Dmitry -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 11:28 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 11:28 UTC (permalink / raw) To: Dmitry Baryshkov Cc: fshao, daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, daniel, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, linux-arm-kernel, angelogioacchino.delregno, Jason-JH Lin (林睿祥), linux-kernel, manasi.d.navare, tzimmermann, freedreno, nicholas.kazlauskas On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote: > On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > > > External email : Please do not click links or open attachments until > > > > you have verified the sender or the content. > > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > > Hi Maxime, Daniel, > > > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > > disabling > > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > > drm_atomic_wait_for_vblank() is set to true. > > > > > As the result, we are not actually waiting for a vlbank to wait for > > > > our > > > > > hardware to close the cursor plane. Subsequently, the execution > > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > > > Could you please apply this patch to fix our problem? > > > > > Or are there any considerations for not applying this patch? > > > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > > land > > > > it. > > > > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > > > There's also the potential issue that it might slow down some of the > > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > > think > > > > all the drivers where this matters have switched over to the async > > > > plane > > > > update stuff meanwhile. So hopefully that's good. > > > > > > > > > > I think all the drivers should have switched to async plane update. > > > > > > Can we add the checking condition to see if atomic_async_update/check > > > function are implemented? > > > > Pretty sure not all have done that, so really it boils down to whether we > > break a real user's use-case. Which pretty much can only be checked by > > merging the patch (hence the requirement to get as many acks as possible > > from display drivers) and then being willing to handle any fallout that's > > reported as regressions for a specific driver. > > > > It's a pile of work, at least when it goes south, that's why I'm looking > > for volunteers. > > I can check this on all sensible msm generations, including mdp4, but > it will be next week, after the FOSDEM. > > BTW, for technical reasons one of the msm platforms still has the > legacy cursor implementation might it be related? Yeah, msm is one of the drivers I had to change with some hacks to avoid really bad fallout. It should still work like before, but that's one that definitely needs testing. -Sima > > > > > Note that handling the fallout doesn't mean you have to fix that specific > > driver, the only realistic option might be to reinstate the legacy cursor > > behaviour, but as an explicit opt-in that only that specific driver > > enables. > > > > So maybe for next round of that patch it might be good to have a 2nd patch > > which implements this fallback plan in the shared atomic modeset code? > > > > Cheers, Sima > > > -- > With best wishes > Dmitry -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 11:28 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 11:28 UTC (permalink / raw) To: Dmitry Baryshkov Cc: fshao, daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, daniel, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, Jason-JH Lin (林睿祥), linux-kernel, manasi.d.navare, tzimmermann, freedreno, nicholas.kazlauskas On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote: > On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > > > External email : Please do not click links or open attachments until > > > > you have verified the sender or the content. > > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > > Hi Maxime, Daniel, > > > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > > disabling > > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > > drm_atomic_wait_for_vblank() is set to true. > > > > > As the result, we are not actually waiting for a vlbank to wait for > > > > our > > > > > hardware to close the cursor plane. Subsequently, the execution > > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > > > Could you please apply this patch to fix our problem? > > > > > Or are there any considerations for not applying this patch? > > > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > > land > > > > it. > > > > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > > > There's also the potential issue that it might slow down some of the > > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > > think > > > > all the drivers where this matters have switched over to the async > > > > plane > > > > update stuff meanwhile. So hopefully that's good. > > > > > > > > > > I think all the drivers should have switched to async plane update. > > > > > > Can we add the checking condition to see if atomic_async_update/check > > > function are implemented? > > > > Pretty sure not all have done that, so really it boils down to whether we > > break a real user's use-case. Which pretty much can only be checked by > > merging the patch (hence the requirement to get as many acks as possible > > from display drivers) and then being willing to handle any fallout that's > > reported as regressions for a specific driver. > > > > It's a pile of work, at least when it goes south, that's why I'm looking > > for volunteers. > > I can check this on all sensible msm generations, including mdp4, but > it will be next week, after the FOSDEM. > > BTW, for technical reasons one of the msm platforms still has the > legacy cursor implementation might it be related? Yeah, msm is one of the drivers I had to change with some hacks to avoid really bad fallout. It should still work like before, but that's one that definitely needs testing. -Sima > > > > > Note that handling the fallout doesn't mean you have to fix that specific > > driver, the only realistic option might be to reinstate the legacy cursor > > behaviour, but as an explicit opt-in that only that specific driver > > enables. > > > > So maybe for next round of that patch it might be good to have a 2nd patch > > which implements this fallback plan in the shared atomic modeset code? > > > > Cheers, Sima > > > -- > With best wishes > Dmitry -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 11:28 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 11:28 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Jason-JH Lin (林睿祥), linux-kernel, linux-mediatek, michel, intel-gfx, chunkuang.hu, linux-arm-msm, mikita.lipski, tzimmermann, maxime, daniel.vetter, nicholas.kazlauskas, dri-devel, quic_abhinavk, Project_Global_Chrome_Upstream_Group, manasi.d.navare, lucas.demarchi, sean, matthias.bgg, dmitry.osipenko, fshao, linux-arm-kernel, jani.nikula, angelogioacchino.delregno, freedreno, daniel, daniel.vetter On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote: > On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > > > External email : Please do not click links or open attachments until > > > > you have verified the sender or the content. > > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > > Hi Maxime, Daniel, > > > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > > disabling > > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > > drm_atomic_wait_for_vblank() is set to true. > > > > > As the result, we are not actually waiting for a vlbank to wait for > > > > our > > > > > hardware to close the cursor plane. Subsequently, the execution > > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > > > Could you please apply this patch to fix our problem? > > > > > Or are there any considerations for not applying this patch? > > > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > > land > > > > it. > > > > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > > > There's also the potential issue that it might slow down some of the > > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > > think > > > > all the drivers where this matters have switched over to the async > > > > plane > > > > update stuff meanwhile. So hopefully that's good. > > > > > > > > > > I think all the drivers should have switched to async plane update. > > > > > > Can we add the checking condition to see if atomic_async_update/check > > > function are implemented? > > > > Pretty sure not all have done that, so really it boils down to whether we > > break a real user's use-case. Which pretty much can only be checked by > > merging the patch (hence the requirement to get as many acks as possible > > from display drivers) and then being willing to handle any fallout that's > > reported as regressions for a specific driver. > > > > It's a pile of work, at least when it goes south, that's why I'm looking > > for volunteers. > > I can check this on all sensible msm generations, including mdp4, but > it will be next week, after the FOSDEM. > > BTW, for technical reasons one of the msm platforms still has the > legacy cursor implementation might it be related? Yeah, msm is one of the drivers I had to change with some hacks to avoid really bad fallout. It should still work like before, but that's one that definitely needs testing. -Sima > > > > > Note that handling the fallout doesn't mean you have to fix that specific > > driver, the only realistic option might be to reinstate the legacy cursor > > behaviour, but as an explicit opt-in that only that specific driver > > enables. > > > > So maybe for next round of that patch it might be good to have a 2nd patch > > which implements this fallback plan in the shared atomic modeset code? > > > > Cheers, Sima > > > -- > With best wishes > Dmitry -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks @ 2024-01-31 11:28 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2024-01-31 11:28 UTC (permalink / raw) To: Dmitry Baryshkov Cc: daniel.vetter, dri-devel, daniel.vetter, Project_Global_Chrome_Upstream_Group, dmitry.osipenko, intel-gfx, chunkuang.hu, daniel, jani.nikula, linux-arm-msm, michel, lucas.demarchi, quic_abhinavk, linux-mediatek, maxime, matthias.bgg, mikita.lipski, sean, linux-arm-kernel, angelogioacchino.delregno, Jason-JH Lin (林睿祥), linux-kernel, manasi.d.navare, tzimmermann, freedreno, nicholas.kazlauskas On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote: > On Wed, 31 Jan 2024 at 11:11, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote: > > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > > > External email : Please do not click links or open attachments until > > > > you have verified the sender or the content. > > > > On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote: > > > > > Hi Maxime, Daniel, > > > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > > disabling > > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > > drm_atomic_wait_for_vblank() is set to true. > > > > > As the result, we are not actually waiting for a vlbank to wait for > > > > our > > > > > hardware to close the cursor plane. Subsequently, the execution > > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > > > Could you please apply this patch to fix our problem? > > > > > Or are there any considerations for not applying this patch? > > > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > > land > > > > it. > > > > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > > > There's also the potential issue that it might slow down some of the > > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > > think > > > > all the drivers where this matters have switched over to the async > > > > plane > > > > update stuff meanwhile. So hopefully that's good. > > > > > > > > > > I think all the drivers should have switched to async plane update. > > > > > > Can we add the checking condition to see if atomic_async_update/check > > > function are implemented? > > > > Pretty sure not all have done that, so really it boils down to whether we > > break a real user's use-case. Which pretty much can only be checked by > > merging the patch (hence the requirement to get as many acks as possible > > from display drivers) and then being willing to handle any fallout that's > > reported as regressions for a specific driver. > > > > It's a pile of work, at least when it goes south, that's why I'm looking > > for volunteers. > > I can check this on all sensible msm generations, including mdp4, but > it will be next week, after the FOSDEM. > > BTW, for technical reasons one of the msm platforms still has the > legacy cursor implementation might it be related? Yeah, msm is one of the drivers I had to change with some hacks to avoid really bad fallout. It should still work like before, but that's one that definitely needs testing. -Sima > > > > > Note that handling the fallout doesn't mean you have to fix that specific > > driver, the only realistic option might be to reinstate the legacy cursor > > behaviour, but as an explicit opt-in that only that specific driver > > enables. > > > > So maybe for next round of that patch it might be good to have a 2nd patch > > which implements this fallback plan in the shared atomic modeset code? > > > > Cheers, Sima > > > -- > With best wishes > Dmitry -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH 1/3] drm/atomic-helpers: remove legacy_cursor_update hacks
@ 2020-10-21 16:32 Daniel Vetter
2020-10-23 12:26 ` [PATCH] " Daniel Vetter
0 siblings, 1 reply; 80+ messages in thread
From: Daniel Vetter @ 2020-10-21 16:32 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter,
mikita.lipski, Michel Dänzer
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.
For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
Inspired by an amdgpu bug report.
v2: Drop RFC, I think with amdgpu converted over to use
atomic_async_check/commit done in
commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Wed Dec 5 14:59:07 2018 -0500
drm/amd/display: Add fast path for cursor plane updates
we don't have any driver anymore where we have userspace expecting
solid legacy cursor support _and_ they are using the atomic helpers in
their fully glory. So we can retire this.
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Cc: mikita.lipski@amd.com
Cc: Michel Dänzer <michel@daenzer.net>
Cc: harry.wentland@amd.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index a7bcb4b4586c..549a31e6042c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1481,13 +1481,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
int i, ret;
unsigned crtc_mask = 0;
- /*
- * Legacy cursor ioctls are completely unsynced, and userspace
- * relies on that (by doing tons of cursor updates).
- */
- if (old_state->legacy_cursor_update)
- return;
-
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) {
if (!new_crtc_state->active)
continue;
@@ -2106,12 +2099,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
continue;
}
- /* Legacy cursor updates are fully unsynced. */
- if (state->legacy_cursor_update) {
- complete_all(&commit->flip_done);
- continue;
- }
-
if (!new_crtc_state->event) {
commit->event = kzalloc(sizeof(*commit->event),
GFP_KERNEL);
--
2.28.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 80+ messages in thread* [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks 2020-10-21 16:32 [PATCH 1/3] " Daniel Vetter @ 2020-10-23 12:26 ` Daniel Vetter 0 siblings, 0 replies; 80+ messages in thread From: Daniel Vetter @ 2020-10-23 12:26 UTC (permalink / raw) To: DRI Development Cc: Daniel Vetter, Intel Graphics Development, Kazlauskas, Nicholas, Daniel Vetter, mikita.lipski, Michel Dänzer The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit hooks. Support for that for msm and vc4 landed. nouveau and i915 have their own commit routines, doing something similar. For everyone else it's probably better to remove the use-after-free bug, and encourage folks to use the async support instead. The affected drivers which register a legacy cursor plane and don't either use the new async stuff or their own commit routine are: amdgpu, atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. Inspired by an amdgpu bug report. v2: Drop RFC, I think with amdgpu converted over to use atomic_async_check/commit done in commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Date: Wed Dec 5 14:59:07 2018 -0500 drm/amd/display: Add fast path for cursor plane updates we don't have any driver anymore where we have userspace expecting solid legacy cursor support _and_ they are using the atomic helpers in their fully glory. So we can retire this. v3: Paper over msm and i915 regression. The complete_all is the only thing missing afaict. References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: mikita.lipski@amd.com Cc: Michel Dänzer <michel@daenzer.net> Cc: harry.wentland@amd.com Cc: Rob Clark <robdclark@gmail.com> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- drivers/gpu/drm/i915/display/intel_display.c | 13 +++++++++++++ drivers/gpu/drm/msm/msm_atomic.c | 2 ++ 3 files changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index a7bcb4b4586c..549a31e6042c 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1481,13 +1481,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, int i, ret; unsigned crtc_mask = 0; - /* - * Legacy cursor ioctls are completely unsynced, and userspace - * relies on that (by doing tons of cursor updates). - */ - if (old_state->legacy_cursor_update) - return; - for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { if (!new_crtc_state->active) continue; @@ -2106,12 +2099,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } - /* Legacy cursor updates are fully unsynced. */ - if (state->legacy_cursor_update) { - complete_all(&commit->flip_done); - continue; - } - if (!new_crtc_state->event) { commit->event = kzalloc(sizeof(*commit->event), GFP_KERNEL); diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 130303e0298a..4257ad7c69c7 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -16122,6 +16122,19 @@ static int intel_atomic_commit(struct drm_device *dev, state->base.legacy_cursor_update = false; } + /* + * FIXME: Cut over to (async) commit helpers instead of hand-rolling + * everything. + */ + if (state->base.legacy_cursor_update) { + struct intel_crtc_state *new_crtc_state; + struct intel_crtc *crtc; + int i; + + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) + complete_all(&new_crtc_state->uapi.commit->flip_done); + } + ret = intel_atomic_prepare_commit(state); if (ret) { drm_dbg_atomic(&dev_priv->drm, diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 561bfa48841c..e0599b16a4ef 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -215,6 +215,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) /* async updates are limited to single-crtc updates: */ WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); + complete_all(&async_crtc->state->commit->flip_done); + /* * Start timer if we don't already have an update pending * on this crtc: -- 2.28.0 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 80+ messages in thread
end of thread, other threads:[~2024-02-05 13:35 UTC | newest] Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-31 15:20 [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks Daniel Vetter 2022-03-31 15:20 ` [Intel-gfx] " Daniel Vetter 2022-03-31 19:35 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork 2022-03-31 20:10 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork 2022-04-01 8:39 ` [PATCH] " Maxime Ripard 2022-04-01 8:39 ` [Intel-gfx] " Maxime Ripard 2022-04-06 21:57 ` Rob Clark 2022-04-06 21:57 ` [Intel-gfx] " Rob Clark 2022-04-07 1:27 ` Jessica Zhang 2022-04-07 1:27 ` [Intel-gfx] " Jessica Zhang 2022-04-07 9:33 ` Daniel Vetter 2022-04-07 9:33 ` [Intel-gfx] " Daniel Vetter 2022-04-07 22:51 ` Rob Clark 2022-04-07 22:51 ` [Intel-gfx] " Rob Clark 2022-04-07 22:59 ` Abhinav Kumar 2022-04-07 22:59 ` [Intel-gfx] " Abhinav Kumar 2022-04-07 23:12 ` Rob Clark 2022-04-07 23:12 ` [Intel-gfx] " Rob Clark 2022-04-09 4:04 ` Abhinav Kumar 2022-04-09 4:04 ` [Intel-gfx] " Abhinav Kumar 2022-04-12 23:36 ` Abhinav Kumar 2022-04-12 23:36 ` [Intel-gfx] " Abhinav Kumar 2022-04-13 11:20 ` Daniel Vetter 2022-04-13 11:20 ` [Intel-gfx] " Daniel Vetter 2022-04-28 8:08 ` Maxime Ripard 2022-04-28 8:08 ` Maxime Ripard 2022-04-28 12:09 ` Daniel Vetter 2022-04-28 12:09 ` [Intel-gfx] " Daniel Vetter 2022-05-12 8:08 ` Maxime Ripard 2022-05-12 8:08 ` [Intel-gfx] " Maxime Ripard 2022-09-26 15:06 ` Melissa Wen 2022-09-26 15:06 ` [Intel-gfx] " Melissa Wen 2022-04-07 7:49 ` Thomas Zimmermann 2022-04-07 7:49 ` Thomas Zimmermann 2022-04-07 9:30 ` Daniel Vetter 2022-04-07 9:30 ` [Intel-gfx] " Daniel Vetter 2022-04-07 12:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/atomic-helpers: remove legacy_cursor_update hacks (rev2) Patchwork 2022-04-07 13:04 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-04-07 18:35 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork -- strict thread matches above, loose matches on Subject: below -- 2023-02-16 11:12 [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks Daniel Vetter 2023-02-16 11:12 ` Daniel Vetter 2023-02-16 11:12 ` Daniel Vetter 2023-02-22 23:14 ` Rob Clark 2023-02-22 23:14 ` Rob Clark 2023-02-22 23:14 ` Rob Clark 2023-02-22 23:21 ` Rob Clark 2023-02-22 23:21 ` Rob Clark 2023-02-22 23:21 ` Rob Clark 2023-03-07 14:56 ` Maxime Ripard 2023-03-07 14:56 ` Maxime Ripard 2023-03-07 14:56 ` Maxime Ripard 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 2024-01-23 6:09 ` Jason-JH Lin (林睿祥) 2024-01-25 18:17 ` Daniel Vetter 2024-01-25 18:17 ` Daniel Vetter 2024-01-25 18:17 ` Daniel Vetter 2024-01-25 18:17 ` Daniel Vetter 2024-01-25 18:17 ` Daniel Vetter 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 2024-01-31 5:17 ` Jason-JH Lin (林睿祥) 2024-01-31 9:11 ` Daniel Vetter 2024-01-31 9:11 ` Daniel Vetter 2024-01-31 9:11 ` Daniel Vetter 2024-01-31 9:11 ` Daniel Vetter 2024-01-31 9:11 ` Daniel Vetter 2024-01-31 10:26 ` Dmitry Baryshkov 2024-01-31 10:26 ` Dmitry Baryshkov 2024-01-31 10:26 ` Dmitry Baryshkov 2024-01-31 11:28 ` Daniel Vetter 2024-01-31 11:28 ` Daniel Vetter 2024-01-31 11:28 ` Daniel Vetter 2024-01-31 11:28 ` Daniel Vetter 2024-01-31 11:28 ` Daniel Vetter 2020-10-21 16:32 [PATCH 1/3] " Daniel Vetter 2020-10-23 12:26 ` [PATCH] " Daniel Vetter
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.