On 2018-05-07 15:59, Peter Rosin wrote: > On 2018-05-07 15:39, Daniel Vetter wrote: >> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote: >>> On 2018-05-03 11:06, Daniel Vetter wrote: >>>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote: >>>>> The more natural approach would perhaps be to add an drm_bridge_add, >>>>> but there are several other bridges that never call drm_bridge_add. >>>>> Just removing the drm_bridge_remove is the easier fix. >>>>> >>>>> Signed-off-by: Peter Rosin <peda@xxxxxxxxxx> >>>> >>>> This mess is much bigger. There's 2 pairs of bridge functions: >>>> >>>> - drm_bridge_attach/detach. Those are meant to be called by the overall >>>> drm driver to connect/disconnect a drm_bridge. >>>> >>>> - drm_bridge_add/remove. These are supposed to be called by the bridge >>>> driver itself to register/unregister itself. Maybe we should rename >>>> them, since the same issue happens with drm_panel, with the same >>>> confusion. >>>> >>>> I thought someone was working on a cleanup series to fix this mess, but I >>>> didn't find anything. >>> >>> Ok, I just spotted the imbalance and didn't really dig into what >>> actually happens in these error paths. Now that I have done so I >>> believe that the removed drm_bridge_remove calls causes NULL >>> dereferences if/when the error paths are triggered. >>> >>> So, I don't think this can wait for some bigger cleanup. >>> >>> drm_bridge_remove calls list_del_init calls __list_del_entry calls >>> __list_del with NULL in both prev and next since the list member >>> is never initialized. prev and next are dereferenced by __list_del >>> and you have *boom* >>> >>> I recommend adding the tag >>> >>> Fixes: 84601dbdea36 ("drm: sti: rework init sequence") >>> >>> so that stable picks this one up. >> >> I just wanted to correct your commit message text - the correct solution >> is definitely _not_ for sti here to call drm_bridge_add. > > Ah, I see what you mean. Do you want me to respin? Hold on, no I don't agree. sti_hda.c does create a bridge for it's own internal use. It does not drm_bridge_add it, because all that ever does is adding the bridge to the global lost of bridges. But since this is a bridge for internal use, there is little point in calling drm_bridge_add, the driver currently gains nothing by doing so. But, drm_bridge_add might be a good place to put common stuff for every bridge in the system, so it might be worthwhile to start requiring all bridges to be drm_bridge_add-ed. And IMHO, it would not be wrong to have the sti-hda driver call drm_bridge_add on the bridge it creates. Do you really think it is actively wrong to call drm_bridge_add for internal bridges such as this? Cheers, Peter _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel