From: sashiko-bot@kernel.org
To: "John Harrison" <John.Harrison@Igalia.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v8 3/8] drm/amd/display: use drmm_writeback_connector_init()
Date: Thu, 23 Jul 2026 00:53:20 +0000 [thread overview]
Message-ID: <20260723005320.BE8621F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723003205.330362-4-John.Harrison@Igalia.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Mismatched object lifetimes in KUnit test causes Use-After-Free when DRM device is torn down.
Pre-existing issues:
- [High] The struct dc_writeback_info allocated dynamically in dm_set_writeback() is leaked on every successful writeback job setup.
--
--- Patch [3]: [PATCH v8 3/8] drm/amd/display: use drmm_writeback_connector_init() ---
commit 4cc9223584993bb5748e535854c7b5fb0eba8f0d
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
drm/amd/display: use drmm_writeback_connector_init()
The driver uses drmm_writeback_connector_init() to ensure proper job queue
cleanup. It also allocates a simple encoder using drmm_plain_encoder_alloc()
for the writeback connector.
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 289da9d00b056..ff7b21830fce9 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5048,7 +5048,7 @@ static void dm_set_writeback(struct amdgpu_display_manager *dm,
> return;
> }
>
> - acrtc = to_amdgpu_crtc(wb_conn->encoder.crtc);
> + acrtc = to_amdgpu_crtc(crtc_state->base.crtc);
> if (!acrtc) {
> drm_err(adev_to_drm(adev), "no amdgpu_crtc found\n");
> kfree(wb_info);
[Severity: High]
This isn't a bug introduced by this patch, but does dm_set_writeback() leak
the dynamically allocated wb_info struct on success?
When userspace configures a writeback job, wb_info is allocated dynamically
using kzalloc_obj(). It is then passed to dc_stream_add_writeback():
dc_stream_add_writeback(dm->dc, crtc_state->stream, wb_info);
acrtc->wb_conn = wb_conn;
drm_writeback_queue_job(wb_conn, new_con_state);
However, dc_stream_add_writeback() copies the contents by value into an array
(stream->writeback_info[...] = *wb_info) but does not take ownership of the
pointer.
The function then returns without ever calling kfree(wb_info) on the success
path, which seems to result in a memory leak on every successful writeback
job setup.
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c
> index 9e7bad4d6ed0c..2bb86218e80b0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c
[ ... ]
> @@ -197,17 +196,26 @@ int amdgpu_dm_wb_connector_init(struct amdgpu_display_manager *dm,
> struct dc *dc = dm->dc;
> struct dc_link *link = dc_get_link_at_index(dc, link_index);
> int res;
> + struct drm_encoder *encoder;
> +
> + encoder = drmm_plain_encoder_alloc(&dm->adev->ddev, NULL,
> + DRM_MODE_ENCODER_VIRTUAL, NULL);
> + if (IS_ERR(encoder))
> + return PTR_ERR(encoder);
> +
> + drm_encoder_helper_add(encoder, &amdgpu_dm_wb_encoder_helper_funcs);
> +
> + encoder->possible_crtcs = amdgpu_dm_get_encoder_crtc_mask(dm->adev);
>
> wbcon->link = link;
>
> drm_connector_helper_add(&wbcon->base.base, &amdgpu_dm_wb_conn_helper_funcs);
>
> - res = drm_writeback_connector_init(&dm->adev->ddev, &wbcon->base,
> + res = drmm_writeback_connector_init(&dm->adev->ddev, &wbcon->base,
> &amdgpu_dm_wb_connector_funcs,
> - &amdgpu_dm_wb_encoder_helper_funcs,
> + encoder,
> amdgpu_dm_wb_formats,
> - ARRAY_SIZE(amdgpu_dm_wb_formats),
> - amdgpu_dm_get_encoder_crtc_mask(dm->adev));
> + ARRAY_SIZE(amdgpu_dm_wb_formats));
[Severity: Medium]
Can this conversion to drmm_writeback_connector_init() cause a use-after-free
in the KUnit tests during DRM device teardown?
In the KUnit test dm_test_wb_connector_init_success(), the mock DRM device is
allocated via dm_kunit_alloc_adev() (which registers a KUnit cleanup action).
The test object wbcon is then allocated using kunit_kzalloc():
wbcon = kunit_kzalloc(test, sizeof(*wbcon), GFP_KERNEL);
KUNIT_ASSERT_NOT_NULL(test, wbcon);
ret = amdgpu_dm_wb_connector_init(dm, wbcon, 0);
Because KUnit cleanup actions run in LIFO order, when the test completes, it
first frees wbcon via kfree(), and then tears down the mock DRM device.
The device teardown triggers the drmm cleanup action registered by this patch
(drm_writeback_connector_cleanup), which will dereference the already-freed
wbcon to lock job_lock and iterate job_queue.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260723003205.330362-1-John.Harrison@Igalia.com?part=3
next prev parent reply other threads:[~2026-07-23 0:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 0:31 [PATCH v8 0/8] drm: writeback: clean up writeback connector initialization John Harrison
2026-07-23 0:31 ` [PATCH v8 1/8] drm/managed: implement managed versions of kzalloc_obj/objs() John Harrison
2026-07-23 0:31 ` [PATCH v8 2/8] drm/amd/display: use drmm allocation for writeback connector John Harrison
2026-07-23 0:54 ` sashiko-bot
2026-07-23 0:31 ` [PATCH v8 3/8] drm/amd/display: use drmm_writeback_connector_init() John Harrison
2026-07-23 0:53 ` sashiko-bot [this message]
2026-07-23 0:31 ` [PATCH v8 4/8] drm/komeda: " John Harrison
2026-07-23 1:02 ` sashiko-bot
2026-07-23 0:32 ` [PATCH v8 5/8] drm/mali: " John Harrison
2026-07-23 0:32 ` [PATCH v8 6/8] drm: renesas: rcar-du: " John Harrison
2026-07-23 0:32 ` [PATCH v8 7/8] drm/vc4: " John Harrison
2026-07-23 0:53 ` sashiko-bot
2026-07-23 0:32 ` [PATCH v8 8/8] drm: writeback: drop excess connector initialization functions John Harrison
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=20260723005320.BE8621F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=John.Harrison@Igalia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.