Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Wed, Feb 22, 2023 at 3:14 PM Rob Clark wrote: > > On Thu, Feb 16, 2023 at 3:12 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 > > 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.32] refcount_t: underflow; use-after-free. > [ +0.33] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 > refcount_warn_saturate+0xf8/0x134 > [ +0.43] 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.16] Hardware name: Google Wormdingler rev1+ INX panel board (DT) > [ +0.08] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ +0.13] pc : refcount_warn_saturate+0xf8/0x134 > [ +0.11] lr : refcount_warn_saturate+0xf8/0x134 > [ +0.11] sp : ffc012e43930 > [ +0.08] x29: ffc012e43930 x28: ff80d31aa300 x27: > 024e > [ +0.17] x26: 03bd x25: 0040 x24: > 0040 > [ +0.14] x23: ff8083eb1000 x22: 0002 x21: > ff80845bc800 > [ +0.13] x20: 0040 x19: ff80d0cecb00 x18: > 60014024 > [ +0.12] x17: x16: 003c x15: > ffd97e21a1c0 > [ +0.12] x14: 0003 x13: 0004 x12: > 0001 > [ +0.14] x11: c000dfff x10: ffd97f560f50 x9 : > 5749cdb403550d00 > [ +0.14] x8 : 5749cdb403550d00 x7 : x6 : > 372e31332020205b > [ +0.12] x5 : ffd97f7b8b24 x4 : x3 : > ffc012e43588 > [ +0.13] x2 : ffc012e43590 x1 : dfff x0 : > 0026 > [ +0.14] Call trace: > [ +0.08] refcount_warn_saturate+0xf8/0x134 > [ +0.13] drm_crtc_commit_put+0x54/0x74 > [ +0.13] __drm_atomic_helper_plane_destroy_state+0x64/0x68 > [ +0.13] dpu_plane_destroy_state+0x24/0x3c > [ +0.17] drm_atomic_state_default_clear+0x13c/0x2d8 > [ +0.15] __drm_atomic_state_free+0x88/0xa0 > [ +0.15] drm_atomic_helper_update_plane+0x158/0x188 > [ +0.14] __setplane_atomic+0xf4/0x138 > [ +0.12] drm_mode_cursor_common+0x2e8/0x40c > [ +0.09] drm_mode_cursor_ioctl+0x48/0x70 > [ +0.08] drm_ioctl_kernel+0xe0/0x158 > [ +0.14] drm_ioctl+0x214/0x480 > [ +0.12] __arm64_sys_ioctl+0x94/0xd4 > [ +0.10] invoke_syscall+0x4c/0x100 > [ +0.13] do_el0_svc+0xa4/0x168 > [ +0.12] el0_svc+0x20/0x50 > [ +0.09] el0t_64_sync_handler+0x20/0x110 > [ +0.08] el0t_64_sync+0x1a4/0x1a8 > [ +0.10] ---[ end trace 35bb2d245a684c9a ]--- > without the
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Feb 16, 2023 at 3:12 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 > 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.32] refcount_t: underflow; use-after-free. [ +0.33] WARNING: CPU: 6 PID: 1854 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x134 [ +0.43] 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.16] Hardware name: Google Wormdingler rev1+ INX panel board (DT) [ +0.08] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.13] pc : refcount_warn_saturate+0xf8/0x134 [ +0.11] lr : refcount_warn_saturate+0xf8/0x134 [ +0.11] sp : ffc012e43930 [ +0.08] x29: ffc012e43930 x28: ff80d31aa300 x27: 024e [ +0.17] x26: 03bd x25: 0040 x24: 0040 [ +0.14] x23: ff8083eb1000 x22: 0002 x21: ff80845bc800 [ +0.13] x20: 0040 x19: ff80d0cecb00 x18: 60014024 [ +0.12] x17: x16: 003c x15: ffd97e21a1c0 [ +0.12] x14: 0003 x13: 0004 x12: 0001 [ +0.14] x11: c000dfff x10: ffd97f560f50 x9 : 5749cdb403550d00 [ +0.14] x8 : 5749cdb403550d00 x7 : x6 : 372e31332020205b [ +0.12] x5 : ffd97f7b8b24 x4 : x3 : ffc012e43588 [ +0.13] x2 : ffc012e43590 x1 : dfff x0 : 0026 [ +0.14] Call trace: [ +0.08] refcount_warn_saturate+0xf8/0x134 [ +0.13] drm_crtc_commit_put+0x54/0x74 [ +0.13] __drm_atomic_helper_plane_destroy_state+0x64/0x68 [ +0.13] dpu_plane_destroy_state+0x24/0x3c [ +0.17] drm_atomic_state_default_clear+0x13c/0x2d8 [ +0.15] __drm_atomic_state_free+0x88/0xa0 [ +0.15] drm_atomic_helper_update_plane+0x158/0x188 [ +0.14] __setplane_atomic+0xf4/0x138 [ +0.12] drm_mode_cursor_common+0x2e8/0x40c [ +0.09] drm_mode_cursor_ioctl+0x48/0x70 [ +0.08] drm_ioctl_kernel+0xe0/0x158 [ +0.14] drm_ioctl+0x214/0x480 [ +0.12] __arm64_sys_ioctl+0x94/0xd4 [ +0.10] invoke_syscall+0x4c/0x100 [ +0.13] do_el0_svc+0xa4/0x168 [ +0.12] el0_svc+0x20/0x50 [ +0.09] el0t_64_sync_handler+0x20/0x110 [ +0.08] el0t_64_sync+0x1a4/0x1a8 [ +0.10] ---[ end trace 35bb2d245a684c9a ]--- BR, -R > Cc: Abhinav Kumar > Cc: Thomas Zimmermann > Cc: Maxime Ripard > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > References: > https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?
[Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 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 Cc: Thomas Zimmermann Cc: Maxime Ripard References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 References: https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard Tested-by: Maxime Ripard Cc: mikita.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark Cc: "Kazlauskas, Nicholas" Cc: Dmitry Osipenko Cc: Maarten Lankhorst Cc: Dmitry Baryshkov Cc: Sean Paul Cc: Matthias Brugger Cc: AngeloGioacchino Del Regno Cc: "Ville Syrjälä" Cc: Jani Nikula Cc: Lucas De Marchi Cc: Imre Deak Cc: Manasi Navare Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Signed-off-by: Daniel Vetter --- 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/gp
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On 04/13, Daniel Vetter wrote: On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar 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 > >> 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 > 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 > >> 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-max...@cerno.tech/ > >> > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >> Cc: Maxime Ripard > >> Tested-by: Maxime Ripard > >> Cc: mikita.lip...@amd.com > >> Cc: Michel Dänzer > >> Cc: harry.wentl...@amd.com > >> Cc: Rob Clark > > > > 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 crt
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 > > 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 > > > >> 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 > > > 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 > > > >> 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-max...@cerno.tech/ > > > >> > > > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > > >> Cc: Maxime Ripard > > > >> Tested-by: Maxime Ripard > > > >> Cc: mikita.lip...@amd.com > > > >> Cc: Michel Dänzer > > > >> Cc: harry.wentl...@amd.com > > > >> Cc: Rob Clark > > > > > > > > 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 t
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 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 > > >> 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 > > 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 > > >> 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-max...@cerno.tech/ > > >> > > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > >> Cc: Maxime Ripard > > >> Tested-by: Maxime Ripard > > >> Cc: mikita.lip...@amd.com > > >> Cc: Michel Dänzer > > >> Cc: harry.wentl...@amd.com > > >> Cc: Rob Clark > > > > > > 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; > > } > > > > -
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar 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 > >> 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 > 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 > >> 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-max...@cerno.tech/ > >> > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >> Cc: Maxime Ripard > >> Tested-by: Maxime Ripard > >> Cc: mikita.lip...@amd.com > >> Cc: Michel Dänzer > >> Cc: harry.wentl...@amd.com > >> Cc: Rob Clark > > > > 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,
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 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 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 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-max...@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard Tested-by: Maxime Ripard Cc: mikita.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark 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: DrmThrea
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On 4/7/2022 4:12 PM, Rob Clark wrote: On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar 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 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 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-max...@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard Tested-by: Maxime Ripard Cc: mikita.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark 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: GW 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 e5912cd286513b064a82a38938b3fdef86b079aa [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen (rev4) (DT) [ 3092.630492] pstate: 8049 (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 : ffc00c1e3760 [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27: 0425 [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24: ffdf8ae3b6f0 [ 3092.665522] x23: x22: x21: ff809b82da00 [ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18: 1000 [ 3092.680255] x17: 0400 x16: 0100 x15: 003b [ 3092.687622] x14: x13: 0002 x12: 0003 [ 3092.694979] x11: ff8084009000 x10: 0040 x9 : 0040 [ 3092.702340] x8 : 0300 x7 : 000c x6 : 0004 [ 3092.709698] x5 : 0320 x4 : 0018 x3 : [ 3092.717056] x2 : x1 : 7bfb38b2a3a89800 x0 : ff809a1eb300 [ 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+0x
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar 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 > > 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 > >>> 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-max...@cerno.tech/ > >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > >>> Cc: Maxime Ripard > >>> Tested-by: Maxime Ripard > >>> Cc: mikita.lip...@amd.com > >>> Cc: Michel Dänzer > >>> Cc: harry.wentl...@amd.com > >>> Cc: Rob Clark > >> > >> 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: GW > >>5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > >> e5912cd286513b064a82a38938b3fdef86b079aa > >> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > >> (rev4) (DT) > >> [ 3092.630492] pstate: 8049 (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 : ffc00c1e3760 > >> [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27: > >> 0425 > >> [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24: > >> ffdf8ae3b6f0 > >> [ 3092.665522] x23: x22: x21: > >> ff809b82da00 > >> [ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18: > >> 1000 > >> [ 3092.680255] x17: 0400 x16: 0100 x15: > >> 003b > >> [ 3092.687622] x14: x13: 0002 x12: > >> 0003 > >> [ 3092.694979] x11: ff8084009000 x10: 0040 x9 : > >> 0040 > >> [ 3092.702340] x8 : 0300 x7 : 000c x6 : > >> 0004 > >> [ 3092.709698] x5 : 0320 x4 : 0018 x3 : > >> > >> [ 3092.717056] x2 : x1 : 7bfb38b2a3a89800 x0 : > >> ff809a1eb300 > >> [ 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 > >> [ 3
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 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 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-max...@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard Tested-by: Maxime Ripard Cc: mikita.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark 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: GW 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 e5912cd286513b064a82a38938b3fdef86b079aa [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen (rev4) (DT) [ 3092.630492] pstate: 8049 (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 : ffc00c1e3760 [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27: 0425 [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24: ffdf8ae3b6f0 [ 3092.665522] x23: x22: x21: ff809b82da00 [ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18: 1000 [ 3092.680255] x17: 0400 x16: 0100 x15: 003b [ 3092.687622] x14: x13: 0002 x12: 0003 [ 3092.694979] x11: ff8084009000 x10: 0040 x9 : 0040 [ 3092.702340] x8 : 0300 x7 : 000c x6 : 0004 [ 3092.709698] x5 : 0320 x4 : 0018 x3 : [ 3092.717056] x2 : x1 : 7bfb38b2a3a89800 x0 : ff809a1eb300 [ 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.21] 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 (
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Wed, Apr 6, 2022 at 6:27 PM 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 > > 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-max...@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard > > Tested-by: Maxime Ripard > > Cc: mikita.lip...@amd.com > > Cc: Michel Dänzer > > Cc: harry.wentl...@amd.com > > Cc: Rob Clark > > 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: GW > 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > e5912cd286513b064a82a38938b3fdef86b079aa > [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > (rev4) (DT) > [ 3092.630492] pstate: 8049 (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 : ffc00c1e3760 > [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27: > 0425 > [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24: > ffdf8ae3b6f0 > [ 3092.665522] x23: x22: x21: > ff809b82da00 > [ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18: > 1000 > [ 3092.680255] x17: 0400 x16: 0100 x15: > 003b > [ 3092.687622] x14: x13: 0002 x12: > 0003 > [ 3092.694979] x11: ff8084009000 x10: 0040 x9 : > 0040 > [ 3092.702340] x8 : 0300 x7 : 000c x6 : > 0004 > [ 3092.709698] x5 : 0320 x4 : 0018 x3 : > > [ 3092.717056] x2 : x1 : 7bfb38b2a3a89800 x0 : > ff809a1eb300 > [ 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.21] 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
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 > > 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-max...@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard > > Tested-by: Maxime Ripard > > Cc: mikita.lip...@amd.com > > Cc: Michel Dänzer > > Cc: harry.wentl...@amd.com > > Cc: Rob Clark > > 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: GW > 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 > e5912cd286513b064a82a38938b3fdef86b079aa > [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen > (rev4) (DT) > [ 3092.630492] pstate: 8049 (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 : ffc00c1e3760 > [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27: > 0425 > [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24: > ffdf8ae3b6f0 > [ 3092.665522] x23: x22: x21: > ff809b82da00 > [ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18: > 1000 > [ 3092.680255] x17: 0400 x16: 0100 x15: > 003b > [ 3092.687622] x14: x13: 0002 x12: > 0003 > [ 3092.694979] x11: ff8084009000 x10: 0040 x9 : > 0040 > [ 3092.702340] x8 : 0300 x7 : 000c x6 : > 0004 > [ 3092.709698] x5 : 0320 x4 : 0018 x3 : > > [ 3092.717056] x2 : x1 : 7bfb38b2a3a89800 x0 : > ff809a1eb300 > [ 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.21] 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): [] > exit_to_kernel_mode+0x10c/0x11c > [ 3092.831523] hardirqs last disabled at (55940): [] > el1_dbg+0x28/0x70 > [ 3092.839577] softirqs last
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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_c...@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 > > 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-max...@cerno.tech/ > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > Cc: Maxime Ripard > > Tested-by: Maxime Ripard > > Cc: mikita.lip...@amd.com > > Cc: Michel Dänzer > > Cc: harry.wentl...@amd.com > > Cc: Rob Clark > > Cc: "Kazlauskas, Nicholas" > > Cc: Dmitry Osipenko > > Signed-off-by: Daniel Vetter > > --- > > 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; > > +
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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_c...@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 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-max...@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard Tested-by: Maxime Ripard Cc: mikita.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark Cc: "Kazlauskas, Nicholas" Cc: Dmitry Osipenko Signed-off-by: Daniel Vetter --- 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_com
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 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-max...@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard Tested-by: Maxime Ripard Cc: mikita.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark 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: GW 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155 e5912cd286513b064a82a38938b3fdef86b079aa [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen (rev4) (DT) [ 3092.630492] pstate: 8049 (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 : ffc00c1e3760 [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27: 0425 [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24: ffdf8ae3b6f0 [ 3092.665522] x23: x22: x21: ff809b82da00 [ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18: 1000 [ 3092.680255] x17: 0400 x16: 0100 x15: 003b [ 3092.687622] x14: x13: 0002 x12: 0003 [ 3092.694979] x11: ff8084009000 x10: 0040 x9 : 0040 [ 3092.702340] x8 : 0300 x7 : 000c x6 : 0004 [ 3092.709698] x5 : 0320 x4 : 0018 x3 : [ 3092.717056] x2 : x1 : 7bfb38b2a3a89800 x0 : ff809a1eb300 [ 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.21] 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): [] exit_to_kernel_mode+0x10c/0x11c [ 3092.831523] hardirqs last disabled at (55940): [] el1_dbg+0x28/0x70 [ 3092.839577] softirqs last enabled at (55938): [] __do_softirq+0x1e8/0x480 [ 3092.848256] softirqs last disabled at (55923): [] __irq_exit_rcu+0xdc/0x140 [ 3092.857022] ---[ end trace ]--- Thanks, Jessica Zhang Cc: "Kazlauskas, Nicholas" Cc: Dmitry Osipenko Signed-off-by: Daniel Vetter --- 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 delet
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Mar 31, 2022 at 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 > 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-max...@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard > Tested-by: Maxime Ripard > Cc: mikita.lip...@amd.com > Cc: Michel Dänzer > Cc: harry.wentl...@amd.com > Cc: Rob Clark > Cc: "Kazlauskas, Nicholas" > Cc: Dmitry Osipenko > Signed-off-by: Daniel Vetter Tested-by: Rob Clark Reviewed-by: Rob Clark > --- > 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_
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 > 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-max...@cerno.tech/ > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > Cc: Maxime Ripard > Tested-by: Maxime Ripard > Cc: mikita.lip...@amd.com > Cc: Michel Dänzer > Cc: harry.wentl...@amd.com > Cc: Rob Clark > Cc: "Kazlauskas, Nicholas" > Cc: Dmitry Osipenko > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime
[Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 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-max...@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard Tested-by: Maxime Ripard Cc: mikita.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark Cc: "Kazlauskas, Nicholas" Cc: Dmitry Osipenko Signed-off-by: Daniel Vetter --- 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
[Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
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 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.lip...@amd.com Cc: Michel Dänzer Cc: harry.wentl...@amd.com Cc: Rob Clark Cc: "Kazlauskas, Nicholas" Signed-off-by: Daniel Vetter --- 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx