| Message ID | 20230216111214.3489223-1-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | drm/atomic-helpers: remove legacy_cursor_update hacks | expand |
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 >
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 > >
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
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
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
On Thu, Jan 25, 2024 at 07:17:21PM +0100, Daniel Vetter wrote: > 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. I think there was also a regression with msm no one really figured out? Maxime
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 >
On Sun, 2024-01-28 at 10:24 +0100, Maxime Ripard wrote: > On Thu, Jan 25, 2024 at 07:17:21PM +0100, Daniel Vetter wrote: > > 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. > > I think there was also a regression with msm no one really figured > out? OK... But I am only available on MediaTek platform. Does it also causes a regression with msn if I re-send a patch for drm_atomic_helper.c only? Regards, Jason-JH.Lin > > Maxime
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 > >
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
Hi, On Wed, Jan 31, 2024 at 05:27:14AM +0000, Jason-JH Lin (林睿祥) wrote: > > On Sun, 2024-01-28 at 10:24 +0100, Maxime Ripard wrote: > > On Thu, Jan 25, 2024 at 07:17:21PM +0100, Daniel Vetter wrote: > > > 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. > > > > I think there was also a regression with msm no one really figured > > out? > > OK... > But I am only available on MediaTek platform. I think most of us are in that situation, and which is part of the reason it kind of stalled :) > Does it also causes a regression with msn if I re-send a patch for > drm_atomic_helper.c only? Yes, that's my recollection at least. Fortunately, Dmitry might be able to clear that up. Maxime
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
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:
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(-)