All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>
Cc: "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"daniel.vetter@intel.com" <daniel.vetter@intel.com>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"dmitry.osipenko@collabora.com" <dmitry.osipenko@collabora.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"jani.nikula@intel.com" <jani.nikula@intel.com>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"michel@daenzer.net" <michel@daenzer.net>,
	"lucas.demarchi@intel.com" <lucas.demarchi@intel.com>,
	"quic_abhinavk@quicinc.com" <quic_abhinavk@quicinc.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"maxime@cerno.tech" <maxime@cerno.tech>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"mikita.lipski@amd.com" <mikita.lipski@amd.com>,
	"sean@poorly.run" <sean@poorly.run>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"manasi.d.navare@intel.com" <manasi.d.navare@intel.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	"freedreno@lists.freedesktop.org"
	<freedreno@lists.freedesktop.org>,
	"nicholas.kazlauskas@amd.com" <nicholas.kazlauskas@amd.com>
Subject: Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
Date: Thu, 25 Jan 2024 19:17:21 +0100	[thread overview]
Message-ID: <ZbKlsTEvGPiGtzS3@phenom.ffwll.local> (raw)
In-Reply-To: <aac416742920953999a9ce230ac68139bf5b9790.camel@mediatek.com>

On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime, Daniel,
> 
> We encountered similar issue with mediatek SoCs.
> 
> We have found that in drm_atomic_helper_commit_rpm(), when disabling
> the cursor plane, the old_state->legacy_cursor_update in
> drm_atomic_wait_for_vblank() is set to true.
> As the result, we are not actually waiting for a vlbank to wait for our
> hardware to close the cursor plane. Subsequently, the execution
> proceeds to drm_atomic_helper_cleanup_planes() to  free the cursor
> buffer. This can lead to use-after-free issues with our hardware.
> 
> Could you please apply this patch to fix our problem?
> Or are there any considerations for not applying this patch?

Mostly it needs someone to collect a pile of acks/tested-by and then land
it.

I'd be _very_ happy if someone else can take care of that ...

There's also the potential issue that it might slow down some of the
legacy X11 use-cases that really needed a non-blocking cursor, but I think
all the drivers where this matters have switched over to the async plane
update stuff meanwhile. So hopefully that's good.

Cheers, Sima
> 
> Regards,
> Jason-JH.Lin
> 
> On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote:
> > > The stuff never really worked, and leads to lots of fun because it
> > > out-of-order frees atomic states. Which upsets KASAN, among other
> > > things.
> > > 
> > > For async updates we now have a more solid solution with the
> > > ->atomic_async_check and ->atomic_async_commit hooks. Support for
> > > that
> > > for msm and vc4 landed. nouveau and i915 have their own commit
> > > routines, doing something similar.
> > > 
> > > For everyone else it's probably better to remove the use-after-free
> > > bug, and encourage folks to use the async support instead. The
> > > affected drivers which register a legacy cursor plane and don't
> > > either
> > > use the new async stuff or their own commit routine are: amdgpu,
> > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and
> > > vmwgfx.
> > > 
> > > Inspired by an amdgpu bug report.
> > 
> > Thanks for submitting that patch. It's been in the downstream RPi
> > tree
> > for a while, so I'd really like it to be merged eventually :)
> > 
> > Acked-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > Maxime

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>
Cc: "maxime@cerno.tech" <maxime@cerno.tech>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"manasi.d.navare@intel.com" <manasi.d.navare@intel.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"michel@daenzer.net" <michel@daenzer.net>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"mikita.lipski@amd.com" <mikita.lipski@amd.com>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"daniel.vetter@intel.com" <daniel.vetter@intel.com>,
	"nicholas.kazlauskas@amd.com" <nicholas.kazlauskas@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"quic_abhinavk@quicinc.com" <quic_abhinavk@quicinc.com>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"lucas.demarchi@intel.com" <lucas.demarchi@intel.com>,
	"sean@poorly.run" <sean@poorly.run>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"dmitry.osipenko@collabora.com" <dmitry.osipenko@collabora.com>,
	"fshao@chromium.org" <fshao@chromium.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"jani.nikula@intel.com" <jani.nikula@intel.com>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>,
	"freedreno@lists.freedesktop.org"
	<freedreno@lists.freedesktop.org>
Subject: Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
Date: Thu, 25 Jan 2024 19:17:21 +0100	[thread overview]
Message-ID: <ZbKlsTEvGPiGtzS3@phenom.ffwll.local> (raw)
In-Reply-To: <aac416742920953999a9ce230ac68139bf5b9790.camel@mediatek.com>

On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime, Daniel,
> 
> We encountered similar issue with mediatek SoCs.
> 
> We have found that in drm_atomic_helper_commit_rpm(), when disabling
> the cursor plane, the old_state->legacy_cursor_update in
> drm_atomic_wait_for_vblank() is set to true.
> As the result, we are not actually waiting for a vlbank to wait for our
> hardware to close the cursor plane. Subsequently, the execution
> proceeds to drm_atomic_helper_cleanup_planes() to  free the cursor
> buffer. This can lead to use-after-free issues with our hardware.
> 
> Could you please apply this patch to fix our problem?
> Or are there any considerations for not applying this patch?

Mostly it needs someone to collect a pile of acks/tested-by and then land
it.

I'd be _very_ happy if someone else can take care of that ...

There's also the potential issue that it might slow down some of the
legacy X11 use-cases that really needed a non-blocking cursor, but I think
all the drivers where this matters have switched over to the async plane
update stuff meanwhile. So hopefully that's good.

Cheers, Sima
> 
> Regards,
> Jason-JH.Lin
> 
> On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote:
> > > The stuff never really worked, and leads to lots of fun because it
> > > out-of-order frees atomic states. Which upsets KASAN, among other
> > > things.
> > > 
> > > For async updates we now have a more solid solution with the
> > > ->atomic_async_check and ->atomic_async_commit hooks. Support for
> > > that
> > > for msm and vc4 landed. nouveau and i915 have their own commit
> > > routines, doing something similar.
> > > 
> > > For everyone else it's probably better to remove the use-after-free
> > > bug, and encourage folks to use the async support instead. The
> > > affected drivers which register a legacy cursor plane and don't
> > > either
> > > use the new async stuff or their own commit routine are: amdgpu,
> > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and
> > > vmwgfx.
> > > 
> > > Inspired by an amdgpu bug report.
> > 
> > Thanks for submitting that patch. It's been in the downstream RPi
> > tree
> > for a while, so I'd really like it to be merged eventually :)
> > 
> > Acked-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > Maxime

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>
Cc: "maxime@cerno.tech" <maxime@cerno.tech>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"manasi.d.navare@intel.com" <manasi.d.navare@intel.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"michel@daenzer.net" <michel@daenzer.net>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"mikita.lipski@amd.com" <mikita.lipski@amd.com>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"daniel.vetter@intel.com" <daniel.vetter@intel.com>,
	"nicholas.kazlauskas@amd.com" <nicholas.kazlauskas@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"quic_abhinavk@quicinc.com" <quic_abhinavk@quicinc.com>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"lucas.demarchi@intel.com" <lucas.demarchi@intel.com>,
	"sean@poorly.run" <sean@poorly.run>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"dmitry.osipenko@collabora.com" <dmitry.osipenko@collabora.com>,
	"fshao@chromium.org" <fshao@chromium.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"jani.nikula@intel.com" <jani.nikula@intel.com>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>,
	"freedreno@lists.freedesktop.org"
	<freedreno@lists.freedesktop.org>
Subject: Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
Date: Thu, 25 Jan 2024 19:17:21 +0100	[thread overview]
Message-ID: <ZbKlsTEvGPiGtzS3@phenom.ffwll.local> (raw)
In-Reply-To: <aac416742920953999a9ce230ac68139bf5b9790.camel@mediatek.com>

On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime, Daniel,
> 
> We encountered similar issue with mediatek SoCs.
> 
> We have found that in drm_atomic_helper_commit_rpm(), when disabling
> the cursor plane, the old_state->legacy_cursor_update in
> drm_atomic_wait_for_vblank() is set to true.
> As the result, we are not actually waiting for a vlbank to wait for our
> hardware to close the cursor plane. Subsequently, the execution
> proceeds to drm_atomic_helper_cleanup_planes() to  free the cursor
> buffer. This can lead to use-after-free issues with our hardware.
> 
> Could you please apply this patch to fix our problem?
> Or are there any considerations for not applying this patch?

Mostly it needs someone to collect a pile of acks/tested-by and then land
it.

I'd be _very_ happy if someone else can take care of that ...

There's also the potential issue that it might slow down some of the
legacy X11 use-cases that really needed a non-blocking cursor, but I think
all the drivers where this matters have switched over to the async plane
update stuff meanwhile. So hopefully that's good.

Cheers, Sima
> 
> Regards,
> Jason-JH.Lin
> 
> On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote:
> > > The stuff never really worked, and leads to lots of fun because it
> > > out-of-order frees atomic states. Which upsets KASAN, among other
> > > things.
> > > 
> > > For async updates we now have a more solid solution with the
> > > ->atomic_async_check and ->atomic_async_commit hooks. Support for
> > > that
> > > for msm and vc4 landed. nouveau and i915 have their own commit
> > > routines, doing something similar.
> > > 
> > > For everyone else it's probably better to remove the use-after-free
> > > bug, and encourage folks to use the async support instead. The
> > > affected drivers which register a legacy cursor plane and don't
> > > either
> > > use the new async stuff or their own commit routine are: amdgpu,
> > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and
> > > vmwgfx.
> > > 
> > > Inspired by an amdgpu bug report.
> > 
> > Thanks for submitting that patch. It's been in the downstream RPi
> > tree
> > for a while, so I'd really like it to be merged eventually :)
> > 
> > Acked-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > Maxime

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>
Cc: "fshao@chromium.org" <fshao@chromium.org>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"daniel.vetter@intel.com" <daniel.vetter@intel.com>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"dmitry.osipenko@collabora.com" <dmitry.osipenko@collabora.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"jani.nikula@intel.com" <jani.nikula@intel.com>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"michel@daenzer.net" <michel@daenzer.net>,
	"lucas.demarchi@intel.com" <lucas.demarchi@intel.com>,
	"quic_abhinavk@quicinc.com" <quic_abhinavk@quicinc.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"maxime@cerno.tech" <maxime@cerno.tech>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"mikita.lipski@amd.com" <mikita.lipski@amd.com>,
	"sean@poorly.run" <sean@poorly.run>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"manasi.d.navare@intel.com" <manasi.d.navare@intel.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	"freedreno@lists.freedesktop.org"
	<freedreno@lists.freedesktop.org>,
	"nicholas.kazlauskas@amd.com" <nicholas.kazlauskas@amd.com>
Subject: Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
Date: Thu, 25 Jan 2024 19:17:21 +0100	[thread overview]
Message-ID: <ZbKlsTEvGPiGtzS3@phenom.ffwll.local> (raw)
In-Reply-To: <aac416742920953999a9ce230ac68139bf5b9790.camel@mediatek.com>

On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime, Daniel,
> 
> We encountered similar issue with mediatek SoCs.
> 
> We have found that in drm_atomic_helper_commit_rpm(), when disabling
> the cursor plane, the old_state->legacy_cursor_update in
> drm_atomic_wait_for_vblank() is set to true.
> As the result, we are not actually waiting for a vlbank to wait for our
> hardware to close the cursor plane. Subsequently, the execution
> proceeds to drm_atomic_helper_cleanup_planes() to  free the cursor
> buffer. This can lead to use-after-free issues with our hardware.
> 
> Could you please apply this patch to fix our problem?
> Or are there any considerations for not applying this patch?

Mostly it needs someone to collect a pile of acks/tested-by and then land
it.

I'd be _very_ happy if someone else can take care of that ...

There's also the potential issue that it might slow down some of the
legacy X11 use-cases that really needed a non-blocking cursor, but I think
all the drivers where this matters have switched over to the async plane
update stuff meanwhile. So hopefully that's good.

Cheers, Sima
> 
> Regards,
> Jason-JH.Lin
> 
> On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote:
> > > The stuff never really worked, and leads to lots of fun because it
> > > out-of-order frees atomic states. Which upsets KASAN, among other
> > > things.
> > > 
> > > For async updates we now have a more solid solution with the
> > > ->atomic_async_check and ->atomic_async_commit hooks. Support for
> > > that
> > > for msm and vc4 landed. nouveau and i915 have their own commit
> > > routines, doing something similar.
> > > 
> > > For everyone else it's probably better to remove the use-after-free
> > > bug, and encourage folks to use the async support instead. The
> > > affected drivers which register a legacy cursor plane and don't
> > > either
> > > use the new async stuff or their own commit routine are: amdgpu,
> > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and
> > > vmwgfx.
> > > 
> > > Inspired by an amdgpu bug report.
> > 
> > Thanks for submitting that patch. It's been in the downstream RPi
> > tree
> > for a while, so I'd really like it to be merged eventually :)
> > 
> > Acked-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > Maxime

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>
Cc: "fshao@chromium.org" <fshao@chromium.org>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"daniel.vetter@intel.com" <daniel.vetter@intel.com>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"dmitry.osipenko@collabora.com" <dmitry.osipenko@collabora.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"jani.nikula@intel.com" <jani.nikula@intel.com>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"michel@daenzer.net" <michel@daenzer.net>,
	"lucas.demarchi@intel.com" <lucas.demarchi@intel.com>,
	"quic_abhinavk@quicinc.com" <quic_abhinavk@quicinc.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"maxime@cerno.tech" <maxime@cerno.tech>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"mikita.lipski@amd.com" <mikita.lipski@amd.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"manasi.d.navare@intel.com" <manasi.d.navare@intel.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	"freedreno@lists.freedesktop.org"
	<freedreno@lists.freedesktop.org>,
	"nicholas.kazlauskas@amd.com" <nicholas.kazlauskas@amd.com>
Subject: Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
Date: Thu, 25 Jan 2024 19:17:21 +0100	[thread overview]
Message-ID: <ZbKlsTEvGPiGtzS3@phenom.ffwll.local> (raw)
In-Reply-To: <aac416742920953999a9ce230ac68139bf5b9790.camel@mediatek.com>

On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime, Daniel,
> 
> We encountered similar issue with mediatek SoCs.
> 
> We have found that in drm_atomic_helper_commit_rpm(), when disabling
> the cursor plane, the old_state->legacy_cursor_update in
> drm_atomic_wait_for_vblank() is set to true.
> As the result, we are not actually waiting for a vlbank to wait for our
> hardware to close the cursor plane. Subsequently, the execution
> proceeds to drm_atomic_helper_cleanup_planes() to  free the cursor
> buffer. This can lead to use-after-free issues with our hardware.
> 
> Could you please apply this patch to fix our problem?
> Or are there any considerations for not applying this patch?

Mostly it needs someone to collect a pile of acks/tested-by and then land
it.

I'd be _very_ happy if someone else can take care of that ...

There's also the potential issue that it might slow down some of the
legacy X11 use-cases that really needed a non-blocking cursor, but I think
all the drivers where this matters have switched over to the async plane
update stuff meanwhile. So hopefully that's good.

Cheers, Sima
> 
> Regards,
> Jason-JH.Lin
> 
> On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote:
> > > The stuff never really worked, and leads to lots of fun because it
> > > out-of-order frees atomic states. Which upsets KASAN, among other
> > > things.
> > > 
> > > For async updates we now have a more solid solution with the
> > > ->atomic_async_check and ->atomic_async_commit hooks. Support for
> > > that
> > > for msm and vc4 landed. nouveau and i915 have their own commit
> > > routines, doing something similar.
> > > 
> > > For everyone else it's probably better to remove the use-after-free
> > > bug, and encourage folks to use the async support instead. The
> > > affected drivers which register a legacy cursor plane and don't
> > > either
> > > use the new async stuff or their own commit routine are: amdgpu,
> > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and
> > > vmwgfx.
> > > 
> > > Inspired by an amdgpu bug report.
> > 
> > Thanks for submitting that patch. It's been in the downstream RPi
> > tree
> > for a while, so I'd really like it to be merged eventually :)
> > 
> > Acked-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > Maxime

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2024-01-25 18:17 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16 11:12 [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks Daniel Vetter
2023-02-16 11:12 ` Daniel Vetter
2023-02-16 11:12 ` [Intel-gfx] " Daniel Vetter
2023-02-16 11:12 ` Daniel Vetter
2023-02-16 15:07 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic-helpers: remove legacy_cursor_update hacks (rev3) Patchwork
2023-02-17  1:11 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-02-22 23:14 ` [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks Rob Clark
2023-02-22 23:14   ` Rob Clark
2023-02-22 23:14   ` [Intel-gfx] " Rob Clark
2023-02-22 23:14   ` Rob Clark
2023-02-22 23:21   ` Rob Clark
2023-02-22 23:21     ` Rob Clark
2023-02-22 23:21     ` [Intel-gfx] " Rob Clark
2023-02-22 23:21     ` Rob Clark
2023-03-07 14:56 ` Maxime Ripard
2023-03-07 14:56   ` Maxime Ripard
2023-03-07 14:56   ` Maxime Ripard
2023-03-07 14:56   ` [Intel-gfx] " Maxime Ripard
2024-01-23  6:09   ` Jason-JH Lin (林睿祥)
2024-01-23  6:09     ` Jason-JH Lin (林睿祥)
2024-01-23  6:09     ` Jason-JH Lin (林睿祥)
2024-01-23  6:09     ` Jason-JH Lin (林睿祥)
2024-01-23  6:09     ` Jason-JH Lin (林睿祥)
2024-01-25 18:17     ` Daniel Vetter [this message]
2024-01-25 18:17       ` Daniel Vetter
2024-01-25 18:17       ` Daniel Vetter
2024-01-25 18:17       ` Daniel Vetter
2024-01-25 18:17       ` Daniel Vetter
2024-01-28  9:24       ` Maxime Ripard
2024-01-28  9:24         ` Maxime Ripard
2024-01-31  5:27         ` Jason-JH Lin (林睿祥)
2024-01-31  5:27           ` Jason-JH Lin (林睿祥)
2024-01-31  5:27           ` Jason-JH Lin (林睿祥)
2024-01-31 10:57           ` mripard
2024-01-31 10:57             ` mripard
2024-01-31 10:57             ` mripard
2024-01-31 10:57             ` mripard
2024-01-31 10:57             ` mripard
2024-01-31  5:17       ` Jason-JH Lin (林睿祥)
2024-01-31  5:17         ` Jason-JH Lin (林睿祥)
2024-01-31  5:17         ` Jason-JH Lin (林睿祥)
2024-01-31  5:17         ` Jason-JH Lin (林睿祥)
2024-01-31  5:17         ` Jason-JH Lin (林睿祥)
2024-01-31  9:11         ` Daniel Vetter
2024-01-31  9:11           ` Daniel Vetter
2024-01-31  9:11           ` Daniel Vetter
2024-01-31  9:11           ` Daniel Vetter
2024-01-31  9:11           ` Daniel Vetter
2024-01-31 10:26           ` Dmitry Baryshkov
2024-01-31 10:26             ` Dmitry Baryshkov
2024-01-31 10:26             ` Dmitry Baryshkov
2024-01-31 11:28             ` Daniel Vetter
2024-01-31 11:28               ` Daniel Vetter
2024-01-31 11:28               ` Daniel Vetter
2024-01-31 11:28               ` Daniel Vetter
2024-01-31 11:28               ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2022-03-31 15:20 Daniel Vetter
2022-04-01  8:39 ` Maxime Ripard
2022-04-06 21:57 ` Rob Clark
2022-04-07  1:27 ` Jessica Zhang
2022-04-07  9:33   ` Daniel Vetter
2022-04-07 22:51   ` Rob Clark
2022-04-07 22:59     ` Abhinav Kumar
2022-04-07 23:12       ` Rob Clark
2022-04-09  4:04         ` Abhinav Kumar
2022-04-12 23:36           ` Abhinav Kumar
2022-04-13 11:20             ` Daniel Vetter
2022-04-28  8:08               ` Maxime Ripard
2022-04-28 12:09                 ` Daniel Vetter
2022-05-12  8:08                   ` Maxime Ripard
2022-09-26 15:06               ` Melissa Wen
2022-04-07  7:49 ` Thomas Zimmermann
2022-04-07  9:30   ` Daniel Vetter
2020-10-21 16:32 [PATCH 1/3] " Daniel Vetter
2020-10-23 12:26 ` [PATCH] " Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZbKlsTEvGPiGtzS3@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Jason-JH.Lin@mediatek.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=lucas.demarchi@intel.com \
    --cc=manasi.d.navare@intel.com \
    --cc=matthias.bgg@gmail.com \
    --cc=maxime@cerno.tech \
    --cc=michel@daenzer.net \
    --cc=mikita.lipski@amd.com \
    --cc=nicholas.kazlauskas@amd.com \
    --cc=quic_abhinavk@quicinc.com \
    --cc=sean@poorly.run \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.