linux-kernel - Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200721064422.GZ3278063@phenom.ffwll.local>
Date:   Tue, 21 Jul 2020 08:44:22 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Sidong Yang <realwakka@...il.com>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Melissa Wen <melissa.srw@...il.com>,
        Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>,
        Emil Velikov <emil.l.velikov@...il.com>,
        Haneen Mohammed <hamohammed.sa@...il.com>,
        David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

On Tue, Jul 21, 2020 at 05:33:00AM +0000, Sidong Yang wrote:
> Hi, Daniel and Melissa
> 
> I tested some code for this problem trying to find the code that make problem in igt test.
> kms_cursor_crc test in igt test has 3 steps (preparation, test, cleanup). I check each steps
> and I found that without cleanup step, the problem solved.
> In cleanup step, igt test code seems like this.
> 
> drmModeSetCrtc(display->drm_fd, crtc_id, 0 /* fb_id */, 0, 
> 		0 /* x, y */, NULL /* connector */, 0, NULL /* mode */)
> 
> I commented out this function call and there is no problem in executing tests repeatedly.
> I'm trying to find out what's happen in this call. but don't know until now
> I hope this information help to solve the problem.

Ah yes that fits the evidence we have from Melissa pretty well: Not
turning off the CRTC means the next test wont have to turn it back on
again. And the vblank bug seems to be in the code which turns the crtc
back on. At least inserting a vblank wait in there is enough to paper over
all the issues, per Melissa's testing.

So at least we're now fairly confident where the bug is, that's some solid
progress.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch