On 12/11/2025 5:38 AM, Matt Roper wrote:
On Thu, Dec 04, 2025 at 08:44:57PM +0200, Jani Nikula wrote:
On Wed, 03 Dec 2025, Uma Shankar <[email protected]> wrote:
This series intends to add support for Plane Color Management for
Intel platforms. This is based on the design which has been agreed
upon by the community. Series implementing the design for generic
DRM core has been sent out by Alex Hung and Harry Wentland and is
merged to upstream tree:
https://patchwork.freedesktop.org/series/152970/
Thanks for the patches, pushed to topic/drm-intel-plane-color-pipeline,
and sent out the pull request [1].
Drive-by comment, but does this series have some memory leaks? Maybe
I'm missing something, but I see various allocations that don't seem to
have corresponding free's anywhere. E.g., the colorop from
intel_colorop_alloc() doesn't seem to be freed anywhere. And
drm_colorop_pipeline_destroy() / drm_colorop_cleanup() don't seem to be
called from anywhere yet, so I think the state allocated by
drm_colorop_reset() might also be leaking in the intel_display code?
Maybe I'm just overlooking something obvious; I haven't reviewed the
series in depth.
Thank you for the comment Matt. You are probably right, we seemed to
have missed it.
Kmemleak does not seem to care about intel_colorop_alloc(). Probably
because the lifetime of these objects is tied to the driver itself?
It does complain about the kasprintfs used in
_intel_color_pipeline_plane_init().
This is used in amdgpu and vkms too. So they might be missing this too.
Also, I see amd calling drm_colorop_pipeline_destroy() only in the init
failure path. vkms seems to get this right, It calls it from
vkms_destroy(). I can ofcourse be wrong.
Anyway, let me investigate a bit further and hopefully come up with some
fixes.
==
Chaitanya
Matt
BR,
Jani.
[1]
https://lore.kernel.org/all/[email protected]
--
Jani Nikula, Intel
