[V7 05/45] drm/colorop: Introduce new drm_colorop mode object
Harry Wentland
harry.wentland at amd.com
Fri Feb 28 15:55:41 UTC 2025
On 2025-02-25 05:05, Louis Chauvet wrote:
>
>
> Le 20/12/2024 à 05:33, Alex Hung a écrit :
>> From: Harry Wentland <harry.wentland at 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
More information about the amd-gfx
mailing list