linux-kernel - Re: [PATCH 1/2] drm: introduce page_flip

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: <f71df23e-f267-46b7-8fd8-4235e9a7a7fb@mailbox.org>
Date: Wed, 28 Jan 2026 12:26:20 +0100
From: Michel Dänzer <michel.daenzer@...lbox.org>
To: Christian König <christian.koenig@....com>,
 Alex Deucher <alexdeucher@...il.com>,
 Hamza Mahfooz <someguy@...ective-light.com>
Cc: Mario Limonciello <mario.limonciello@....com>,
 Timur Kristóf <timur.kristof@...il.com>,
 dri-devel@...ts.freedesktop.org, Alex Deucher <alexander.deucher@....com>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>,
 Rodrigo Siqueira <siqueira@...lia.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Sunil Khatri <sunil.khatri@....com>, Ce Sun <cesun102@....com>,
 Lijo Lazar <lijo.lazar@....com>, Kenneth Feng <kenneth.feng@....com>,
 Ivan Lipski <ivan.lipski@....com>, Alex Hung <alex.hung@....com>,
 Tom Chung <chiahsuan.chung@....com>, Melissa Wen <mwen@...lia.com>,
 Michel Dänzer <mdaenzer@...hat.com>,
 Fangzhi Zuo <Jerry.Zuo@....com>, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout()

On 1/28/26 11:39, Christian König wrote:
> On 1/27/26 23:57, Alex Deucher wrote:
>> On Tue, Jan 27, 2026 at 5:53 PM Hamza Mahfooz
>> <someguy@...ective-light.com> wrote:
>>>
>>> On Mon, Jan 26, 2026 at 09:20:55AM -0500, Alex Deucher wrote:
>>>> I suspect just calling drm_crtc_send_vblank_event() here on the
>>>> relevant crtcs would be enough.
>>>>
>>>
>>> Seems like an interesting idea, though I would imagine we would still
>>> want to attempt a reset (of some kind) assuming that the subsequent page
>>> flip also experiences a timeout.
>>
>> Is it actually a timeout or just missed interrupts?  I'm wondering if
>> some power feature races with the modeset and causes the interrupt to
>> get missed from time to time.
> 
> That is my strong suspicion as well.
> 
> Even if we missed a vblank interrupt that thing is reoccurring, so the worst thing that can happen is that we delayed reporting back success by one frame.
> 
> So something must have turned the CRTC fully off.

Not sure that's a generally valid conclusion (do the gitlab issues talk about the display going black, or about it staying on but freezing?). AFAIR at least in some cases amdgpu uses a dedicated "page flip" interrupt instead of the vblank interrupt, in which case missing a single interrupt could cause a timeout.


P.S. Completing the atomic commit and sending the completion event must work even if user space turns off any CRTCs as part of the commit[0]. So your hypothesis would be a kernel bug, accidentally turning off the CRTC and/or not handling a CRTC getting turned off correctly.

[0] If any CRTC for which the commit has state is off both before and after the commit though, the commit fails with an error before it could result in a timeout.

-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast