linux-kernel - Re: [PATCH v6 02/10] Revert "drm/qxl: do not run release if qxl failed to init"

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3feaeb62-fd50-5cca-26f7-42f6167ef77a@suse.de>
Date:   Thu, 4 Feb 2021 20:06:53 +0100
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Tong Zhang <ztong0001@...il.com>
Cc:     Gerd Hoffmann <kraxel@...hat.com>, dri-devel@...ts.freedesktop.org,
        David Airlie <airlied@...ux.ie>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:DRM DRIVER FOR QXL VIRTUAL GPU" 
        <virtualization@...ts.linux-foundation.org>,
        "open list:DRM DRIVER FOR QXL VIRTUAL GPU" 
        <spice-devel@...ts.freedesktop.org>,
        Dave Airlie <airlied@...hat.com>
Subject: Re: [PATCH v6 02/10] Revert "drm/qxl: do not run release if qxl
 failed to init"

Hi Tong

Am 04.02.21 um 19:52 schrieb Tong Zhang:
> Hi Thomas,
> 
> The original problem was qxl_device_init() can fail,
> when it fails there is no need to call
> 	qxl_modeset_fini(qdev);
> 	qxl_device_fini(qdev);
> But those two functions are otherwise called in the qxl_drm_release() -

OK, makes sense. Thanks for the explanation.

> 
> I have posted an updated patch.
> The new patch use the following logic
> 
> +	if (!qdev->ddev.mode_config.funcs)
> +	  return;

This is again just papering over the issue. Better don't call 
qxl_drm_release() in the error path if qxl_device_init() fails.

I see two solutions: either roll-back manually, or use our new managed 
DRM interfaces. This is what the other drivers do.

Best regards
Thomas

> 	qxl_modeset_fini(qdev);
> 	qxl_device_fini(qdev);
> 
> Thanks,
> - Tong
> 
> 
>> On Feb 4, 2021, at 1:34 PM, Thomas Zimmermann <tzimmermann@...e.de> wrote:
>>
>> Hi
>>
>> Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
>>> This reverts commit b91907a6241193465ca92e357adf16822242296d.
>>
>> This should be in the correct format, as given by 'dim cite'.
>>
>> dim cite b91907a6241193465ca92e357adf16822242296d
>> b91907a62411 ("drm/qxl: do not run release if qxl failed to init")
>>
>>> Patch is broken, it effectively makes qxl_drm_release() a nop
>>> because on normal driver shutdown qxl_drm_release() is called
>>> *after* drm_dev_unregister().
>>> Cc: Tong Zhang <ztong0001@...il.com>
>>> Signed-off-by: Gerd Hoffmann <kraxel@...hat.com>
>>> ---
>>>   drivers/gpu/drm/qxl/qxl_drv.c | 2 --
>>>   1 file changed, 2 deletions(-)
>>> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
>>> index 34c8b25b5780..fb5f6a5e81d7 100644
>>> --- a/drivers/gpu/drm/qxl/qxl_drv.c
>>> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
>>> @@ -144,8 +144,6 @@ static void qxl_drm_release(struct drm_device *dev)
>>>   	 * reodering qxl_modeset_fini() + qxl_device_fini() calls is
>>>   	 * non-trivial though.
>>>   	 */
>>> -	if (!dev->registered)
>>> -		return;
>>
>> I'm not sure what the original problem was, but I'm sure that this isn't the fix for it. If there's a problem with shutdown, the operations rather have to be reordered correctly.
>>
>> With the citation style address:
>>
>> Acked-by: Thomas Zimmermann <tzimmermann@...e.de>
>>
>>>   	qxl_modeset_fini(qdev);
>>>   	qxl_device_fini(qdev);
>>>   }
>>
>> -- 
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)