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 for Android: free password hash cracker in your pocket

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

Message-ID: <7623f1be-28ce-4111-941c-15e3fcaf0cb9@amd.com>
Date: Wed, 28 Jan 2026 15:35:11 +0100
From: Christian König <christian.koenig@....com>
To: Michel Dänzer <michel.daenzer@...lbox.org>,
 Timur Kristóf <timur.kristof@...il.com>,
 Hamza Mahfooz <someguy@...ective-light.com>, dri-devel@...ts.freedesktop.org
Cc: 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>,
 Fangzhi Zuo <Jerry.Zuo@....com>, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout()

On 1/28/26 15:25, Michel Dänzer wrote:
> On 1/28/26 12:25, Christian König wrote:
>> On 1/28/26 10:19, Timur Kristóf wrote:
>>> On 2026. január 26., hétfő 14:00:59 közép-európai téli idő Christian König 
>>> wrote:
>>>> On 1/26/26 11:27, Michel Dänzer wrote:
>>>>> On 1/26/26 11:14, Christian König wrote:
>>>>>>
>>>>>> But looking at the slide Harry actually pointed out what immediately came
>>>>>> to my mind as well, e.g. that the Compositor needs to issue a full
>>>>>> modeset to re-program the CRTC.> 
>>>>> In principle, the kernel driver has all the information it needs to
>>>>> reprogram the HW by itself. Not sure why the compositor would need to be
>>>>> actively involved.
>>>>
>>>> [...]
>>>>
>>>> Then second even if the kernel can do it I'm not sure if it should do it.
>>>>
>>>> [...]
>>>
>>> I agree with Michel here. It's a kernel bug, it should be solved by the 
>>> kernel. I don't like the tendency of pushing userspace to handle kernel bugs, 
>>> especially if this is just needed for one vendor's buggy driver. (No offence.)
>>
>> Well I strongly disagree. The kernel is not here to serve userspace, [...]
> 
> Can't say I agree with that statement.
> 
> Anyway, user space certainly isn't here to kick the kernel back into gear after it hit a bug, or to tell it things it already knows.

That is a really good argument. But the kernel should also not hide that something went wrong from userspace. E.g. flaky HDP pins for example.

Regards,
Christian.

> 
>