All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.