diff mbox series

[RESEND] drm/vmwgfx: Don't double-free the mode stored in par->set_mode

Message ID 20190318144758.21267-1-tzimmermann@suse.de (mailing list archive)
State New, archived
Headers show
Series [RESEND] drm/vmwgfx: Don't double-free the mode stored in par->set_mode | expand

Commit Message

Thomas Zimmermann March 18, 2019, 2:47 p.m. UTC 
When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing 'old_mode'
in favor of using par->set_mode directly fixes the problem.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

--
2.20.1

Comments

Deepak Singh Rawat March 18, 2019, 4:59 p.m. UTC | #1 
Hi Thomas,

Thanks for doing this and somehow I missed the last patch, sorry about
that. Have some questions below otherwise the patch looks good to me.

Reviewed-by: Deepak Rawat <drawat@vmware.com>

I will include your changes in vmwgfx-next and run tests.

On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote:
> When calling vmw_fb_set_par(), the mode stored in par->set_mode gets
> free'd
> twice. The first free is in vmw_fb_kms_detach(), the second is near
> the
> end of vmw_fb_set_par() under the name of 'old_mode'. The mode-
> setting code
> only works correctly if the mode doesn't actually change.

You mean to say that without your patch vmwgfx fb driver fail to change
the mode?

>  Removing 'old_mode'
> in favor of using par->set_mode directly fixes the problem.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index b913a56f3426..2a9112515f46 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info *info)
>  		0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>  		DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
>  	};
> -	struct drm_display_mode *old_mode;
>  	struct drm_display_mode *mode;
>  	int ret;
> 
> -	old_mode = par->set_mode;
>  	mode = drm_mode_duplicate(vmw_priv->dev, &new_mode);
>  	if (!mode) {
>  		DRM_ERROR("Could not create new fb mode.\n");
> @@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info *info)
>  	mode->vdisplay = var->yres;
>  	vmw_guess_mode_timing(mode);
> 
> -	if (old_mode && drm_mode_equal(old_mode, mode)) {
> -		drm_mode_destroy(vmw_priv->dev, mode);
> -		mode = old_mode;
> -		old_mode = NULL;

I am having hard time understanding original intention for this piece
of code. Was there a restriction to send pointer to old mode if mode
were same and that restriction don't hold anymore. Sorry I am not
familiar with this code area.

> -	} else if (!vmw_kms_validate_mode_vram(vmw_priv,
> +	if (!vmw_kms_validate_mode_vram(vmw_priv,
>  					mode->hdisplay *
>  					DIV_ROUND_UP(var-
> >bits_per_pixel, 8),
>  					mode->vdisplay)) {
> @@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
>  	schedule_delayed_work(&par->local_work, 0);
> 
>  out_unlock:
> -	if (old_mode)
> -		drm_mode_destroy(vmw_priv->dev, old_mode);
> +	if (par->set_mode)
> +		drm_mode_destroy(vmw_priv->dev, par->set_mode);
>  	par->set_mode = mode;
> 
>  	mutex_unlock(&par->bo_mutex);
> --
> 2.20.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Cdrawat%40vmware.com%7Cb1508247a3954fb0b08b08d6abb0bcd0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636885172908359973&amp;sdata=AN6UTrMzxcVK7MC6bX3OxNbcyq0j4HdKt0dk1yyHOHc%3D&amp;reserved=0
Thomas Zimmermann March 19, 2019, 5:56 p.m. UTC | #2 
Hi Deepak

Am 18.03.19 um 17:59 schrieb Deepak Singh Rawat:
> Hi Thomas,
> 
> Thanks for doing this and somehow I missed the last patch, sorry about
> that. Have some questions below otherwise the patch looks good to me.
> 
> Reviewed-by: Deepak Rawat <drawat@vmware.com>
> 
> I will include your changes in vmwgfx-next and run tests.

Thank you.

> 
> On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote:
>> When calling vmw_fb_set_par(), the mode stored in par->set_mode gets
>> free'd
>> twice. The first free is in vmw_fb_kms_detach(), the second is near
>> the
>> end of vmw_fb_set_par() under the name of 'old_mode'. The mode-
>> setting code
>> only works correctly if the mode doesn't actually change.
> 
> You mean to say that without your patch vmwgfx fb driver fail to change
> the mode?

Yes. It's hard to trigger as the usual resolution always appears to be
800x600. We (SUSE) have a customer with a custom X11 modeline setting,
which sets the resolution to something different. In this case, the
double-free bug happens.

> 
>>  Removing 'old_mode'
>> in favor of using par->set_mode directly fixes the problem.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++---------
>>  1 file changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> index b913a56f3426..2a9112515f46 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> @@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info *info)
>>  		0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>>  		DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
>>  	};
>> -	struct drm_display_mode *old_mode;
>>  	struct drm_display_mode *mode;
>>  	int ret;
>>
>> -	old_mode = par->set_mode;
>>  	mode = drm_mode_duplicate(vmw_priv->dev, &new_mode);
>>  	if (!mode) {
>>  		DRM_ERROR("Could not create new fb mode.\n");
>> @@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info *info)
>>  	mode->vdisplay = var->yres;
>>  	vmw_guess_mode_timing(mode);
>>
>> -	if (old_mode && drm_mode_equal(old_mode, mode)) {
>> -		drm_mode_destroy(vmw_priv->dev, mode);
>> -		mode = old_mode;
>> -		old_mode = NULL;
> 
> I am having hard time understanding original intention for this piece
> of code. Was there a restriction to send pointer to old mode if mode
> were same and that restriction don't hold anymore. Sorry I am not
> familiar with this code area.

Hmm, I can only guess about motivation: it looks like the author wanted
to keep the original value of 'par->set_mode' unless the mode really
changes. But it doesn't make a difference whether the pointer's value
changes or not.

Best regards
Thomas

> 
>> -	} else if (!vmw_kms_validate_mode_vram(vmw_priv,
>> +	if (!vmw_kms_validate_mode_vram(vmw_priv,
>>  					mode->hdisplay *
>>  					DIV_ROUND_UP(var-
>>> bits_per_pixel, 8),
>>  					mode->vdisplay)) {
>> @@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
>>  	schedule_delayed_work(&par->local_work, 0);
>>
>>  out_unlock:
>> -	if (old_mode)
>> -		drm_mode_destroy(vmw_priv->dev, old_mode);
>> +	if (par->set_mode)
>> +		drm_mode_destroy(vmw_priv->dev, par->set_mode);
>>  	par->set_mode = mode;
>>
>>  	mutex_unlock(&par->bo_mutex);
>> --
>> 2.20.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Cdrawat%40vmware.com%7Cb1508247a3954fb0b08b08d6abb0bcd0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636885172908359973&amp;sdata=AN6UTrMzxcVK7MC6bX3OxNbcyq0j4HdKt0dk1yyHOHc%3D&amp;reserved=0
>
Thomas Hellstrom March 19, 2019, 6:18 p.m. UTC | #3 
Hi, Deepak,

On Mon, 2019-03-18 at 09:59 -0700, Deepak Singh Rawat wrote:
> Hi Thomas,
> 
> Thanks for doing this and somehow I missed the last patch, sorry
> about
> that. Have some questions below otherwise the patch looks good to me.
> 
> Reviewed-by: Deepak Rawat <drawat@vmware.com>
> 
> I will include your changes in vmwgfx-next and run tests.

I think we need to run this through vmwgfx-fixes and CC stable. I'll
pick up the patch for that.


> 
> On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote:
> > When calling vmw_fb_set_par(), the mode stored in par->set_mode
> > gets
> > free'd
> > twice. The first free is in vmw_fb_kms_detach(), the second is near
> > the
> > end of vmw_fb_set_par() under the name of 'old_mode'. The mode-
> > setting code
> > only works correctly if the mode doesn't actually change.
> 
> You mean to say that without your patch vmwgfx fb driver fail to
> change
> the mode?
> 
> >  Removing 'old_mode'
> > in favor of using par->set_mode directly fixes the problem.
> > 
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++---------
> >  1 file changed, 3 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > index b913a56f3426..2a9112515f46 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > @@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info
> > *info)
> >  		0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> >  		DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
> >  	};
> > -	struct drm_display_mode *old_mode;
> >  	struct drm_display_mode *mode;
> >  	int ret;
> > 
> > -	old_mode = par->set_mode;
> >  	mode = drm_mode_duplicate(vmw_priv->dev, &new_mode);
> >  	if (!mode) {
> >  		DRM_ERROR("Could not create new fb mode.\n");
> > @@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info
> > *info)
> >  	mode->vdisplay = var->yres;
> >  	vmw_guess_mode_timing(mode);
> > 
> > -	if (old_mode && drm_mode_equal(old_mode, mode)) {
> > -		drm_mode_destroy(vmw_priv->dev, mode);
> > -		mode = old_mode;
> > -		old_mode = NULL;
> 
> I am having hard time understanding original intention for this piece
> of code. Was there a restriction to send pointer to old mode if mode
> were same and that restriction don't hold anymore. Sorry I am not
> familiar with this code area.

It looks like that code is there to reuse the old mode if possible. In
that case things work, but if a new mode is indeed created, the old
mode will be double-freed :(

/Thomas



> 
> > -	} else if (!vmw_kms_validate_mode_vram(vmw_priv,
> > +	if (!vmw_kms_validate_mode_vram(vmw_priv,
> >  					mode->hdisplay *
> >  					DIV_ROUND_UP(var-
> > > bits_per_pixel, 8),
> >  					mode->vdisplay)) {
> > @@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
> >  	schedule_delayed_work(&par->local_work, 0);
> > 
> >  out_unlock:
> > -	if (old_mode)
> > -		drm_mode_destroy(vmw_priv->dev, old_mode);
> > +	if (par->set_mode)
> > +		drm_mode_destroy(vmw_priv->dev, par->set_mode);
> >  	par->set_mode = mode;
> > 
> >  	mutex_unlock(&par->bo_mutex);
> > --
> > 2.20.1
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Cdrawat%40vmware.com%7Cb1508247a3954fb0b08b08d6abb0bcd0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636885172908359973&amp;sdata=AN6UTrMzxcVK7MC6bX3OxNbcyq0j4HdKt0dk1yyHOHc%3D&amp;reserved=0
>
diff mbox series

Patch

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index b913a56f3426..2a9112515f46 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -564,11 +564,9 @@  static int vmw_fb_set_par(struct fb_info *info)
 		0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 		DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
 	};
-	struct drm_display_mode *old_mode;
 	struct drm_display_mode *mode;
 	int ret;

-	old_mode = par->set_mode;
 	mode = drm_mode_duplicate(vmw_priv->dev, &new_mode);
 	if (!mode) {
 		DRM_ERROR("Could not create new fb mode.\n");
@@ -579,11 +577,7 @@  static int vmw_fb_set_par(struct fb_info *info)
 	mode->vdisplay = var->yres;
 	vmw_guess_mode_timing(mode);

-	if (old_mode && drm_mode_equal(old_mode, mode)) {
-		drm_mode_destroy(vmw_priv->dev, mode);
-		mode = old_mode;
-		old_mode = NULL;
-	} else if (!vmw_kms_validate_mode_vram(vmw_priv,
+	if (!vmw_kms_validate_mode_vram(vmw_priv,
 					mode->hdisplay *
 					DIV_ROUND_UP(var->bits_per_pixel, 8),
 					mode->vdisplay)) {
@@ -620,8 +614,8 @@  static int vmw_fb_set_par(struct fb_info *info)
 	schedule_delayed_work(&par->local_work, 0);

 out_unlock:
-	if (old_mode)
-		drm_mode_destroy(vmw_priv->dev, old_mode);
+	if (par->set_mode)
+		drm_mode_destroy(vmw_priv->dev, par->set_mode);
 	par->set_mode = mode;

 	mutex_unlock(&par->bo_mutex);