From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5C591CD3F for ; Thu, 16 Jan 2025 11:31:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737027117; cv=none; b=ni67Zj+ckjvoE2LY0Tb+PPCWGOr97odDg6Vj7Typsl6vVrM2O4fsyc7GkwiPjjuzzWc/2d08IrFJpwslx2as/AIIUaEfkbmDteZTGDO+R8rJBvDrtqjpYDkdeVmTqBTM0yDg0hFcpqnW3h6M9XerMqgNQfUBbiYrJ48Gi29PK3c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737027117; c=relaxed/simple; bh=7bQCzCMhaBCC2M4Jn/d5Z5hjxs8cmwqam4mquULnqZo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EDyBEEtuISj055yM4ciF07hk+lP13tkEPbcJR9VchZcYUbfRx1rwYmCmfWi9eRtRtoRKZgyUAu0+Tv++OKaAA+YVVXjOO+Jye2jTTpH7y6dKo+4j08FFmVtHPPgmAMg79NDYZp7k5TF0VkP/Gm3WGFSOYY4/i1KOhvF28RAkrco= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch; spf=none smtp.mailfrom=ffwll.ch; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b=j2VtDNNu; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ffwll.ch Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="j2VtDNNu" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-38a25d4b9d4so455392f8f.0 for ; Thu, 16 Jan 2025 03:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; t=1737027114; x=1737631914; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=vnd6sU73jYDmsrBRXokzbmxa4aS7E80YMwt2n/oQ3g0=; b=j2VtDNNuIVvQheAgazpCScJ7NN9FPmMumCJHu2kmfYWy+hGPD7KGHEUyKojwjNHJpl Yr2PlfAgvUUDW3v/tih/eS2QmhNmh8MJ3yeb4zzvLOJUEKjnaV9bRXltp8eHzc9vykxW ZW3A3UgfccafoJIw0/jvXigWaLpboqY5E6vc4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737027114; x=1737631914; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vnd6sU73jYDmsrBRXokzbmxa4aS7E80YMwt2n/oQ3g0=; b=EskzWG016AShCP45n1r7lGy6CFB8FBZq9vX5dO9MffHGrNShL0zT7r4q5XwHDBrfpf JtahYud5ZN1YWl6J9v35P3yVMGyHSEtAUL/Jjh3V3uL6eFOe8GRSCzY9R0Pfliom0Jnd f3Jr2mG9l0ZZ6R/b5Gqcqhhg+5KG/cc9tVSZDyiljS3ZvNVN1AfACAs/ZFBlsaDc03Iq nR77kO8CtF+xCvAvZFMcMXS7WCtGshSSaMDz4fc50AzHruboecA8xoNxIZsWKzRrtZ0Q thqWsooXVk61zj0DbNRdKH8dK0NvVG7ncShykzFiAc5E8/iObY7YYEPvJnvroSWjo0Ma ZunQ== X-Forwarded-Encrypted: i=1; AJvYcCUMuzUv+yUKtnLyrgFbq1Q+6y4vLRyUIqTS0sfA/dfBQLysV23imT+EcOr7EfSNp+z0BaytZ37gMX6XU7M=@vger.kernel.org X-Gm-Message-State: AOJu0YxsWX9tdWPnzzVwJ/DDD+q9yg/0idbm2IxSqZASySFSJQev+GlY Dk6YHeGRenjUMEXk3d1wgmEzVyar2ZwRwErDEx2NA0iL8sbfFYCR7l2ZdYZ0kjY= X-Gm-Gg: ASbGnctE6MQl/TH6fdhp8X/Mu/ljj75dJsWHIMuo+aGYKAzrtw8G5rWlD5Ld4WdFOyU FK3XyKgQa4vC2emjW0UzHcPsvLEv6TZ+1U9SXtV1yv7rHbIgf1IoR3cvksAaZEQnH+rG+3CXSwT QUHdNkSLCt7q8d8hflYA1lbftQnP67Ts2WxLKESLUNE6ZPiWeKweacNpe/uEnqWkQ3aX0cnkyLl FJRWUc45Fc4548fV0JIfe4whi9liYzFrC4NYvL0BrkQ9cQ5cK7Vg6Fdru9OxwOLTQaP X-Google-Smtp-Source: AGHT+IE8MJdwU7wMyzkJzaEaeAjpV4//EE99bMcQNBFtw2uWo0ACj81i58fz6k6usIbP+ONeTfig4A== X-Received: by 2002:a5d:64eb:0:b0:386:41bd:53a3 with SMTP id ffacd0b85a97d-38a87310667mr28551284f8f.50.1737027114242; Thu, 16 Jan 2025 03:31:54 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:5485:d4b2:c087:b497]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a8e384054sm20295886f8f.36.2025.01.16.03.31.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 03:31:53 -0800 (PST) Date: Thu, 16 Jan 2025 12:31:51 +0100 From: Simona Vetter To: Maxime Ripard Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Douglas Anderson , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 24/29] drm/bridge: Provide a helper to get the global state from a bridge state Message-ID: Mail-Followup-To: Maxime Ripard , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Douglas Anderson , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20250115-bridge-connector-v1-0-9a2fecd886a6@kernel.org> <20250115-bridge-connector-v1-24-9a2fecd886a6@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250115-bridge-connector-v1-24-9a2fecd886a6@kernel.org> X-Operating-System: Linux phenom 6.12.3-amd64 On Wed, Jan 15, 2025 at 10:05:31PM +0100, Maxime Ripard wrote: > We have access to the global drm_atomic_state from a drm_bridge_state, > but since it's fairly indirect it's not as obvious as it can be for > other KMS entities. > > Provide a helper to make it easier to figure out. > > Signed-off-by: Maxime Ripard > --- > include/drm/drm_atomic.h | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h > index 31ca88deb10d262fb3a3f8e14d2afe24f8410cb1..bd7959ae312c99c0a0034d36378ae44f04f6a374 100644 > --- a/include/drm/drm_atomic.h > +++ b/include/drm/drm_atomic.h > @@ -1183,10 +1183,26 @@ static inline struct drm_bridge_state * > drm_priv_to_bridge_state(struct drm_private_state *priv) > { > return container_of(priv, struct drm_bridge_state, base); > } > > +/** > + * @drm_bridge_state_get_atomic_state() - Get the atomic state from a bridge state > + * @bridge_state: bridge state object > + * > + * RETURNS: > + * The global atomic state @bridge_state is a part of, or NULL if there is none. > + */ > +static inline struct drm_atomic_state * > +drm_bridge_state_get_atomic_state(struct drm_bridge_state *bridge_state) So this one is nasty, because we clear out these backpointers once we push the states into obj->state (because they can then outlive the drm_atomic_state). Which means you can't use this in commit callbacks. Or the bridge code has a really bad use-after-free when it doesn't clear out these backpointers when we swap in the new states in drm_atomic_helper_swap_state(). The better pattern is to just ditch passing individual states to callbacks and just pass the entire drm_atomic_state container, and let callbacks fish out what exactly they need. And also provide all necessary helpers to find the right states and all that stuff. We should probably also document that design approach in the kerneldoc for drm_atomic_state, or wherever there's a good place for that. See also my other reply for some of the history of why we have this mess. Cheers, Sima > +{ > + if (!bridge_state) > + return NULL; > + > + return bridge_state->base.state; > +} > + > struct drm_bridge_state * > drm_atomic_get_bridge_state(struct drm_atomic_state *state, > struct drm_bridge *bridge); > struct drm_bridge_state * > drm_atomic_get_old_bridge_state(const struct drm_atomic_state *state, > > -- > 2.47.1 > -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch