Re: [V7 05/45] drm/colorop: Introduce new drm_colorop mode object

[Harry Wentland <harry.wentland@amd.com>]

On 2025-02-25 05:05, Louis Chauvet wrote:
> 
> 
> Le 20/12/2024 à 05:33, Alex Hung a écrit :
>> From: Harry Wentland <harry.wentland@amd.com>
>>
>> @@ -249,6 +255,20 @@ void drm_atomic_state_default_clear(struct 
>> drm_atomic_state *state)
>>           state->planes[i].new_state = NULL;
>>       }
>> +    for (i = 0; i < config->num_colorop; i++) {
>> +        struct drm_colorop *colorop = state->colorops[i].ptr;
>> +
>> +        if (!colorop)
>> +            continue;
>> +
>> +        drm_colorop_atomic_destroy_state(colorop,
>> +                         state->colorops[i].state);
>> +        state->colorops[i].ptr = NULL;
>> +        state->colorops[i].state = NULL;
> 
> There is no risk of use-after-free between the 
> drm_colorop_atomic_destroy_state and the state->colorops[i].state?
> 

This is using the same pattern as all the other DRM objects in this
function. If this was a problem it would've been a problem before this
change.

I don't claim to fully understand the calling code but this is called
from __drm_atomic_state_free and to backoff when an -EDEADLK occurs.
In the latter case it's followed by drm_modeset_backoff which releases
locks in drm_modeset_drop_locks. This seems to indicate that callers
hold the respective locks to protect the state.

Harry