linux-kernel - Re: [PATCH v2 02/22] drm: Add valid clones check

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: <20241216-elated-vagabond-numbat-14fe8f@houat>
Date: Mon, 16 Dec 2024 15:47:23 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Jessica Zhang <quic_jesszhan@...cinc.com>
Cc: Rob Clark <robdclark@...il.com>, 
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, quic_abhinavk@...cinc.com, Sean Paul <sean@...rly.run>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, David Airlie <airlied@...il.com>, 
	Daniel Vetter <daniel@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, quic_ebharadw@...cinc.com, linux-arm-msm@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	Rob Clark <robdclark@...omium.org>, Ville Syrjälä <ville.syrjala@...ux.intel.com>
Subject: Re: [PATCH v2 02/22] drm: Add valid clones check

On Fri, Dec 06, 2024 at 04:48:43PM -0800, Jessica Zhang wrote:
> On 9/25/2024 12:23 AM, Maxime Ripard wrote:
> > On Tue, Sep 24, 2024 at 03:59:18PM GMT, Jessica Zhang wrote:
> > > Check that all encoders attached to a given CRTC are valid
> > > possible_clones of each other.
> > > 
> > > Signed-off-by: Jessica Zhang <quic_jesszhan@...cinc.com>
> > > ---
> > >   drivers/gpu/drm/drm_atomic_helper.c | 23 +++++++++++++++++++++++
> > >   1 file changed, 23 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 43cdf39019a4..cc4001804fdc 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -574,6 +574,25 @@ mode_valid(struct drm_atomic_state *state)
> > >   	return 0;
> > >   }
> > > +static int drm_atomic_check_valid_clones(struct drm_atomic_state *state,
> > > +					 struct drm_crtc *crtc)
> > > +{
> > > +	struct drm_encoder *drm_enc;
> > > +	struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> > > +									  crtc);
> > > +
> > > +	drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc_state->encoder_mask) {
> > > +		if ((crtc_state->encoder_mask & drm_enc->possible_clones) !=
> > > +		    crtc_state->encoder_mask) {
> > > +			DRM_DEBUG("crtc%d failed valid clone check for mask 0x%x\n",
> > > +				  crtc->base.id, crtc_state->encoder_mask);
> > > +			return -EINVAL;
> > > +		}
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > >   /**
> > >    * drm_atomic_helper_check_modeset - validate state object for modeset changes
> > >    * @dev: DRM device
> > > @@ -745,6 +764,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > >   		ret = drm_atomic_add_affected_planes(state, crtc);
> > >   		if (ret != 0)
> > >   			return ret;
> > > +
> > > +		ret = drm_atomic_check_valid_clones(state, crtc);
> > > +		if (ret != 0)
> > > +			return ret;
> > >   	}
> > 
> > Pretty much the same comment, we should have kunit tests for this.
> 
> Hey Maxime,
> 
> I'm working on the kunit test for this and had a question on the design for
> the unit test:
> 
> Since this is a static helper that returns a pretty common error code, how
> would you recommend going about making sure that
> `drm_atomic_check_valid_clones()` specifically is returning the error (and
> not a different part of check_modeset) when testing the check_valid_clones()
> failure path?

There's two ways to go about it. Either you can unit test it, prepare a
series of custom states and use
EXPORT_SYMBOL_FOR_TESTS_ONLY/EXPORT_SYMBOL_IF_KUNIT, or you can go the
integration test way and just test that drm_atomic_check is rejected for
unsafe combinations.

I guess I'd prefer the former, but the latter also makes sense and
eventually, it checks what we want: to make sure that we reject such a
state. What part of the code does or with what error code is less
important imo.

Maxime

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