[PATCH] drm/core: Fix ordering in drm_mode_config_cleanup.
Maarten Lankhorst
maarten.lankhorst at linux.intel.com
Tue Mar 22 15:08:39 UTC 2016
Op 22-03-16 om 15:58 schreef Ville Syrjälä:
> On Tue, Mar 22, 2016 at 03:42:14PM +0100, Maarten Lankhorst wrote:
>> __drm_atomic_helper_plane_destroy_state calls
>> drm_framebuffer_unreference, which means that if drm_framebuffer_free
>> is called before plane->destroy freed memory will be accessed.
>>
>> A similar case happens for the blob list, which was freed before the
>> crtc state was, resulting in the unreference_blob from crtc_destroy_state
>> pointing to garbage memory causing another opportunity for a GPF.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>> ---
>> drivers/gpu/drm/drm_crtc.c | 18 +++++++++---------
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 51c5a00ffdff..5a13b1afccbe 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -5958,6 +5958,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>> drm_property_destroy(dev, property);
>> }
> And what about props? Any chance of explosion due to those being gone?
>
Not as far as I'm aware of.
If you use something like a crtc_x property, only the value gets written to crtc_state, the value is an int that would still be valid.
~Maarten
More information about the dri-devel
mailing list