linux-kernel - Re: [PATCH] 4.15 vmgfx boot warning

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: <1d88409f-23c4-6706-7111-00f2d13f3351@gmail.com>
Date:   Fri, 15 Dec 2017 19:01:34 -0500
From:   Woody Suwalski <terraluna977@...il.com>
To:     Sinclair Yeh <syeh@...are.com>
Cc:     DRI mailing list <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dave Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH] 4.15 vmgfx boot warning

Sinclair Yeh wrote:
> Hi Woody,
>
> On Wed, Nov 22, 2017 at 04:05:50PM -0500, Woody Suwalski wrote:
>> The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
>> It is caused by a mismatch between the result of vmw_enable_vblank() and
>> what the drm_atomic_helper expects:
>>     /...
>>     ret = drm_crtc_vblank_get(crtc);
>>     WARN_ONCE(ret != -EINVAL, "driver forgot to call
>> drm_crtc_vblank_off()\n");
> This doesn't apply to us because we don't have vblank support, and so
> -ENOSYS seems to be the right error.
>
> In the commit message for 84014b0a39ee, it does state a check for this
> condition, but the check itself is based on dev->irq_enabled.
>
> Is there another way to check for vblank support?
>
>
>
>>     /...
>>
>> Signed-off by: Woody Suwalski <terraluna977@...il.com>
>>
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 15:29:46.511674079
>> -0500
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 15:30:35.344559592
>> -0500
>> @@ -1869,7 +1869,7 @@ u32 vmw_get_vblank_counter(struct drm_de
>>    */
>>   int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
>>   {
>> -    return -ENOSYS;
>> +    return -EINVAL;
>>   }
>>
>>   /**
>>
Sinclair, it is a valid stand, so I guess it is time to ask Daniel...

Would it be OK to convert the WARN_ONCE statement in drm_atomic_helper 
to recognize ENOSYS as a valid error? Something like

WARN_ONCE((ret != -EINVAL && ret != _ENOSYS), "driver forgot to call 
drm_crtc_vblank_off()\n");

Thanks, Woody