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@xxxxxxxxxx> > > Maxime
