linux-kernel - Re: [PATCH 01/29] drm/atomic: Document atomic state lifetime

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: <20250923-quantum-resolute-crayfish-681be7@penduick>
Date: Tue, 23 Sep 2025 11:22:21 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	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>, 
	Jyri Sarha <jyri.sarha@....fi>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, 
	Devarsh Thakkar <devarsht@...com>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/29] drm/atomic: Document atomic state lifetime

Hi Thomas,

On Tue, Sep 02, 2025 at 03:08:12PM +0200, Thomas Zimmermann wrote:
> > + *     or a newer one if a commit has been made. The new state is the
> > + *     state we just allocated and we might eventually commit to the
> > + *     hardware. The existing state points to the state we'll eventually
> > + *     have to free, the new state for now.
> 
> That final sentence is confusing. What are we doing with the existing state?

After the other cleanup series I have, existing state is only ever used
to point to the state we should free.

> Will the old state ever become the existing state? You also never explain
> this below.

Yes, after we run an atomic commit. If the commit is only allocated and
freed, or if the atomic is only checked, then we'll free new state. It's
what I tried to explain in the next paragraph, but maybe it's not clear
enough?

> Maybe only focus on the old and new state for now and explain the meaning of
> the existing state in a separate bullet point.

I'll try to do that then, thanks!

> > + *
> > + *   + Once we run a commit, it is first checked and if the check is
> > + *     successful, it is committed. Part of the commit is a call to
> > + *     drm_atomic_helper_swap_state() which will turn the new state into
> > + *     the active state. Doing so involves updating the entity state
> > + *     pointer (&drm_crtc.state or similar) to point to the new state,
> > + *     and the existing state will now point to the old state, that used
> > + *     to be active but isn't anymore.
> > + *
> > + *   + When the commit is done, and when all references to our &struct
> > + *     drm_atomic_state are put, drm_atomic_state_clear() runs and will
> > + *     free all the old states.
> > + *
> > + *   + Now, we don't have any active &struct drm_atomic_state anymore,
> > + *     and only the entity active states remain allocated.
> > + */

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