Archive-only list for syzbot
 help / color / mirror / Atom feed
From: Krystian Kaniewski <krystianmkaniewski@gmail.com>
To: syzbot <syzbot@kernel.org>,
	syzkaller-upstream-moderation@googlegroups.com
Cc: syzbot@lists.linux.dev
Subject: Re: [PATCH RFC] drm/vblank: Replace WARN with drm_err for vblank wait timeouts
Date: Thu, 6 Aug 2026 09:48:33 +0200	[thread overview]
Message-ID: <d7491322-e1c0-4592-af9a-106b28c9ad00@gmail.com> (raw)
In-Reply-To: <7527aaed-dcb2-4bde-a807-1677dcd0af99@mail.kernel.org>

Revise the patch so that it suppresses the vblank warning only for the 
best-effort DRM client/fbdev throttling path reached through 
drm_client_modeset_wait_for_vblank(). Keep the WARN behavior of the 
exported drm_crtc_wait_one_vblank() helper and leave 
drm_atomic_helper_wait_for_vblanks() unchanged, because those 
driver-facing paths can diagnose genuine vblank failures and the atomic 
helper is not in the reported stack.

Implement the narrow behavior through a DRM-internal, non-exported 
warning-free entry point backed by the same wait implementation as 
drm_crtc_wait_one_vblank(). The public helper must retain its existing 
warnings. Preserve the one-second timeout, wait predicate, vblank 
reference balance, exported ABI, public helper return values, and 
drm_client_modeset_wait_for_vblank() semantics: -EBUSY only when an 
external DRM master prevents the wait and zero otherwise. Do not add 
unrelated enabled-state checks, locking changes, CRTC-index validation, 
timer-priority changes, public headers, or atomic-helper changes.

Use `Fixes: d8c4bddcd8bc ("drm/fb-helper: Synchronize dirty worker with 
vblank")`. Explain that PREEMPT_RT can delay VKMS software vblank 
delivery beyond the timeout, and that this is acceptable only for 
optional client update throttling.

On 8/2/2026 11:09 PM, syzbot wrote:
> On PREEMPT_RT kernels, a user-space task with elevated Real-Time (RT)
> priority can starve essential kernel threads. For example, the VKMS driver
> simulates vblank interrupts using hrtimers. On PREEMPT_RT, these timers run
> in the per-CPU timer threads at a low RT priority. If a user-space task
> elevates its priority above the timer thread and monopolizes the CPU, the
> timer thread is starved and the vblank hrtimer never fires.
>
> This leads to a timeout when a worker thread waits for the vblank event.
> For instance, a console update triggers a framebuffer update, scheduling
> drm_fb_helper_damage_work() on the system workqueue. The worker thread
> eventually calls drm_crtc_wait_one_vblank() to synchronize the screen
> update with the vblank interval. Due to the starved timer, the wait times
> out and triggers a drm_WARN. A similar issue exists in
> drm_atomic_helper_wait_for_vblanks() where a WARN is triggered upon
> timeout.
>
> WARN macros must not be used for conditions that can legitimately happen,
> and pr_err or drm_err should be used instead if necessary. Since this
> timeout is an expected consequence of RT scheduling starvation rather than
> a kernel bug, replace the warnings with drm_err(). This ensures the timeout
> is still logged for diagnostic purposes without triggering an unnecessary
> backtrace.
>
> Fixes: 74afeb812850 ("drm/vblank: Add vblank timer")
> Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
> Reported-by: syzbot+f59157955aba9d0cb43b@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=f59157955aba9d0cb43b
> Link: https://syzkaller.appspot.com/ai_job?id=396433fb-a59e-4936-97d4-4d2e7ced2ee9
> To: "David Airlie" <airlied@gmail.com>
> To: <dri-devel@lists.freedesktop.org>
> To: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>
> To: "Maxime Ripard" <mripard@kernel.org>
> To: "Simona Vetter" <simona@ffwll.ch>
> To: "Thomas Zimmermann" <tzimmermann@suse.de>
> Cc: <linux-kernel@vger.kernel.org>
>
> ---
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 51f39edc3..0266beff9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1918,8 +1918,9 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
>   						drm_crtc_vblank_count(crtc),
>   					 msecs_to_jiffies(1000));
>   
> -		WARN(!ret, "[CRTC:%d:%s] vblank wait timed out\n",
> -		     crtc->base.id, crtc->name);
> +		if (!ret)
> +			drm_err(dev, "[CRTC:%d:%s] vblank wait timed out\n",
> +				crtc->base.id, crtc->name);
>   
>   		drm_crtc_vblank_put(crtc);
>   	}
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index f90fb2d13..7f7f4dd35 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -1326,7 +1326,8 @@ int drm_crtc_wait_one_vblank(struct drm_crtc *crtc)
>   				 last != drm_vblank_count(dev, pipe),
>   				 msecs_to_jiffies(1000));
>   
> -	drm_WARN(dev, ret == 0, "vblank wait timed out on crtc %i\n", pipe);
> +	if (ret == 0)
> +		drm_err(dev, "vblank wait timed out on crtc %i\n", pipe);
>   
>   	drm_vblank_put(dev, pipe);
>   
>
>
> base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff

      reply	other threads:[~2026-08-06  7:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 21:09 [PATCH RFC] drm/vblank: Replace WARN with drm_err for vblank wait timeouts syzbot
2026-08-06  7:48 ` Krystian Kaniewski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d7491322-e1c0-4592-af9a-106b28c9ad00@gmail.com \
    --to=krystianmkaniewski@gmail.com \
    --cc=syzbot@kernel.org \
    --cc=syzbot@lists.linux.dev \
    --cc=syzkaller-upstream-moderation@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox