Re: [PATCH v3] drm/vblank: downgrade vblank wait timeout from WARN to error

[Chintan Patel <chintanlike@gmail.com>]

Hi Thomas,

Thank you Thomas for suggestions!

On 10/24/25 06:58, Thomas Zimmermann wrote:
> Hi
> 
> Am 03.10.25 um 05:23 schrieb Chintan Patel:
>> When wait_event_timeout() in drm_wait_one_vblank() times out, the
>> current WARN can cause unnecessary kernel panics in environments
>> with panic_on_warn set (e.g. CI, fuzzing). These timeouts can happen
>> under heavy scheduling pressure or in rare cases of delayed vblank
>> handling, and are not always a kernel bug.
>>
>> Replace the WARN with drm_err() messages that report the timeout
>> without crashing the system. Developers can still enable drm.debug
>> to diagnose genuine problems.
>>
>> Reported-by: syzbot+147ba789658184f0ce04@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=147ba789658184f0ce04
>> Tested-by: syzbot+147ba789658184f0ce04@syzkaller.appspotmail.com
>> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
>>
>> v2:
>>   - Drop unnecessary in-code comment (suggested by Thomas Zimmermann)
>>   - Remove else branch, only log timeout case
>>
>> v3:
>>   - Use drm_err() instead of drm_dbg_kms() (suggested by Ville Syrjälä)
>>   - Remove unnecessary curr = drm_vblank_count() (suggested by Thomas 
>> Zimmermann)
>>   - Fix commit message wording (“invalid userspace calls” → “delayed 
>> vblank handling”)
>> ---
>>   drivers/gpu/drm/drm_vblank.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>> index 46f59883183d..0664aea1b924 100644
>> --- a/drivers/gpu/drm/drm_vblank.c
>> +++ b/drivers/gpu/drm/drm_vblank.c
>> @@ -1305,7 +1305,8 @@ void drm_wait_one_vblank(struct drm_device *dev, 
>> unsigned int pipe)
>>                    last != drm_vblank_count(dev, pipe),
>>                    msecs_to_jiffies(100));
> 
> Instead of replacing the drm_WARN(), could you please try to increase 
> the timeout? Let's say 1000 msec to be on the safe side.
> 

I tried it locally and also tested with syzbot after increasing the 
timeout to 1000 msec. The issue no longer reproduces with this change.

I’ll send v4 shortly with the updated timeout.