linux-kernel - Re: [PATCH v3 31/37] drm/bridge: Provide pointers to the connector and crtc in bridge state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250219-gregarious-condor-of-prestige-a6ce0c@houat>
Date: Wed, 19 Feb 2025 16:56:11 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Andrzej Hajda <andrzej.hajda@...el.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, 
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Douglas Anderson <dianders@...omium.org>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 31/37] drm/bridge: Provide pointers to the connector
 and crtc in bridge state

On Wed, Feb 19, 2025 at 02:35:25PM +0100, Simona Vetter wrote:
> On Tue, Feb 18, 2025 at 11:23:00AM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > Thanks for your answer
> > 
> > On Mon, Feb 17, 2025 at 05:41:24PM +0100, Simona Vetter wrote:
> > > On Thu, Feb 13, 2025 at 03:43:50PM +0100, Maxime Ripard wrote:
> > > > Now that connectors are no longer necessarily created by the bridges
> > > > drivers themselves but might be created by drm_bridge_connector, it's
> > > > pretty hard for bridge drivers to retrieve pointers to the connector and
> > > > CRTC they are attached to.
> > > > 
> > > > Indeed, the only way to retrieve the CRTC is to follow the drm_bridge
> > > > encoder field, and then the drm_encoder crtc field, both of them being
> > > > deprecated.
> > > 
> > > Eh, this isn't quite how this works. So unless bridges have become very
> > > dynamic and gained flexible routing the bridge(->bridge->...)->encoder
> > > chain is static. And the crtc for an encoder you find by walking the
> > > connector states in a drm_atomic_state, finding the right one that points
> > > at your encoder, and then return the ->crtc pointer from that connector
> > > state.
> > > 
> > > It's a bit bonkers, but I think it's better to compute this than adding
> > > more pointers that potentially diverge. Unless there's a grand plan here,
> > > but then I think we want some safety checks that all the pointers never
> > > get out of sync here.
> > 
> > That work stemed from this series
> > https://lore.kernel.org/all/20250210132620.42263-1-herve.codina@bootlin.com/
> > 
> > and in particular:
> > https://lore.kernel.org/all/20250210132620.42263-5-herve.codina@bootlin.com/
> > 
> > Bridges, outside of the modesetting code path, don't have a way to
> > access the drm_atomic_state since drm_bridge_state->state is typically
> > cleared after swap_state. So accessing the connectors and CRTCs don't
> > work anymore.
> > 
> > In this particular case, we needed to access those from the bridge
> > interrupt handler.
> 
> Uh for interrupt handler you can't use anything stored in state objects
> anyway. So I'm even more confused.

Why not? As long as we're in a threaded handler, and take the proper
locks, what's wrong with it, and how is it fundamentally different than,
idk, cec or audio hooks?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)