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] [day] [month] [year] [list]

Message-ID: <7563faa3-a326-4cb8-9eeb-93ba53a22215@quicinc.com>
Date: Mon, 16 Dec 2024 11:47:01 -0800
From: Jessica Zhang <quic_jesszhan@...cinc.com>
To: Maxime Ripard <mripard@...nel.org>
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 12/16/2024 6:47 AM, Maxime Ripard wrote:
> 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.

Thanks for confirming! The changes I made are based on the latter 
approach. Will post the changes later today if you have no objections on 
this

Thanks,

Jessica Zhang

> 
> Maxime