[PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.

Daniel Vetter daniel at ffwll.ch
Wed May 27 08:27:31 UTC 2020

On Tue, May 26, 2020 at 01:11:28PM +0200, Daniel Vetter wrote:
> On Tue, May 26, 2020 at 6:39 AM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
> >
> > On 2020/05/26 13:18, Tetsuo Handa wrote:
> > > due to mode->crtc_clock <= 0. Thus, somehow initializing mode->crtc_clock > 0 might be able
> > > to solve this problem.
> >
> > Well, I came to think that vkms_enable_vblank() should return an error to the caller
> > when drm_calc_timestamping_constants() failed...
> If my memory is right we shouldn't even get there. crtc->mode being
> all zeros sounds like the simulated output isn't on (no surprise,
> syzbot doesn't enable it and fbcon is probably on card0), so something
> higher up should reject this. I'll see whether I can figure out what
> vkms isn't doing right (or whether there's a higher level bug in
> drm_vblank.c code), yesterday my machine died and already evening
> anyway.
> Thanks for digging into this a bit more meanwhile.

Ok good news, I think I have a fix. Bad news it's code used by like 50
drivers, so this will take some time to get reviewed and merged (and I
think almost all these other drivers are buggy too, which is why I decided
to fix the shared code).

Patch below, can you pls confirm this fixes it?

Thanks, Daniel

commit b882894ac0fce412b67db79a5c92f2b599ec5069
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date:   Tue May 26 14:29:00 2020 +0200

    drm/atomic-helper: reset vblank on crtc reset
    Only when vblanks are supported ofc.
    Some drivers do this already, but most unfortunately missed it. This
    opens up bugs after driver load, before the crtc is enabled for the
    first time. syzbot spotted this when loading vkms as a secondary
    output. Given how many drivers are buggy it's best to solve this once
    and for all in shared helper code.
    Aside from moving the few existing calls to drm_crtc_vblank_reset into
    helpers (i915 doesn't use helpers, so keeps its own) I think the
    regression risk is minimal: atomic helpers already rely on drivers
    calling drm_crtc_vblank_on/off correctly in their hooks when they
    support vblanks. And driver that's failing to handle vblanks after
    this is missing those calls already, and vblanks could only work by
    accident when enabling a CRTC for the first time right after boot.
    FIXME: Fix up drivers and audit them all.
    Big thanks to Tetsuo for helping track down what's going wrong here.
    Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
    Reported-by: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
    Reported-by: syzbot+0871b14ca2e2fb64f6e3 at syzkaller.appspotmail.com
    Cc: stable at vger.kernel.org
    Cc: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
    Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 8fce6a115dfe..843964252239 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -32,6 +32,7 @@
 #include <drm/drm_device.h>
 #include <drm/drm_plane.h>
 #include <drm/drm_print.h>
+#include <drm/drm_vblank.h>
 #include <drm/drm_writeback.h>
 #include <linux/slab.h>
@@ -93,6 +94,9 @@ __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
 	if (crtc_state)
 		__drm_atomic_helper_crtc_state_reset(crtc_state, crtc);
+	if (crtc->dev->num_crtcs)
+		drm_crtc_vblank_reset(crtc);
 	crtc->state = crtc_state;
Daniel Vetter
Software Engineer, Intel Corporation

More information about the dri-devel mailing list