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-a1bb1dcbf...@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-92fb40d27...@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
