Re: [REGRESSION] drm/panel/panel-simple v6.17 WARNING regression

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hello Ernest,

On Tue Oct 14, 2025 at 1:25 PM CEST, Ernest Van Hoecke wrote:
> Hi Luca,
>
> Thanks for your fast reply and all your work here.
>
> On Tue, Oct 14, 2025 at 12:31:35PM +0200, Luca Ceresoli wrote:
>> Let me have a look at the DRM_IMX driver, I'll try to send a series
>> converting it to the new API within today.
>
> I will gladly test, thanks!

Just sent:
https://lore.kernel.org/all/20251014-drm-bridge-alloc-imx-ipuv3-v1-0-a1bb1dcbff50@bootlin.com/

>> I recently sent a series proposing to make drm_bridge_add() mandatory
>> before drm_bridge_attach() in the docs and warn if that is violated [1]. If
>> you apply patch 4 of that series you should see the warning.
>
> I gave it a quick try and did not see the warning. Some printk debugging
> told me that `list_empty(&bridge->list)`, inside drm_bridge_attach, is
> returning 0.

Ouch, I think this is because without using devm_drm_bridge_alloc() even
the list is uninitialized, and so list_empty will do:

static inline int list_empty(const struct list_head *head)
{
	return READ_ONCE(head->next) == head;
	                        ^         ^
                NULL (bridge->list      valid pointer
                zeroed by kzalloc)      to bridge->list
}

So it returns false. I guess that means the series to make drm_bridge_add()
mandatory before drm_bridge_attach() [0] will need a better check to
trigger the warning.

[0] https://lore.kernel.org/lkml/20251003-b4-drm-bridge-alloc-add-before-attach-v1-0-92fb40d27704@bootlin.com/

>> > However, later on, another regression seems to be introduced by
>> > commit 8fa5909400f3 ("drm/bridge: get the bridge returned by drm_bridge_chain_get_first_bridge()")
>> > so reverting 94d50c1a2ca3 on top of drm-misc-next does not solve
>> > everything. This was tested by rebasing drm-misc-next onto (260f6f4fda93
>> > plus the revert of 94d50c1a2ca3) and then bisecting.
>> >
>> > So in v6.18-rc1, both regressions are present.
>> >
>> > There, I get the following additional warnings:
>> >
>> > [    9.732278] ------------[ cut here ]------------
>> > [    9.732336] WARNING: CPU: 0 PID: 38 at lib/refcount.c:22 drm_bridge_get+0x10/0x18
>> > [    9.744608] refcount_t: saturated; leaking memory.
>>
>> Not sure here, but it may well be another symptom of the same bug: the
>> refcount was not initialized correctly, so it is found inconsistent later
>> when trying to increase it. Let's fix the known issue and then we'll see.
>
> Makes sense to me.

Alright. Let me know whether the series I've sent fixes 0, 1 or both
warnings.

Best regards,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com