<html><body><p>
<pre>
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
>
</pre>
</p></body></html><!--type:text--><!--{--><pre>************* MEDIATEK Confidentiality Notice ********************
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful. If you are not an intended recipient of this e-mail, or believe
that you have received this e-mail in error, please notify the sender
immediately (by replying to this e-mail), delete any and all copies of
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
</pre><!--}-->