linux-kernel - Re: [PATCH] drm/doc: Define KMS atomic state set

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: <orevvhcz7e4p7ztincqegggfstkfz5jv7w2ugqpdqadvkfwzig@oxf5k2pgdd4t>
Date:   Mon, 4 Dec 2023 13:20:00 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc:     Pekka Paalanen <pekka.paalanen@...labora.com>,
        André Almeida <andrealmeid@...lia.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Jonathan Corbet <corbet@....net>,
        'Marek Olšák' <maraeo@...il.com>,
        Michel Dänzer <michel.daenzer@...lbox.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-doc@...r.kernel.org, Thomas Zimmermann <tzimmermann@...e.de>,
        kernel-dev@...lia.com, alexander.deucher@....com,
        christian.koenig@....com
Subject: Re: [PATCH] drm/doc: Define KMS atomic state set

On Fri, Dec 01, 2023 at 08:09:22PM +0200, Ville Syrjälä wrote:
> > When I was working on Weston atomic KMS support many years ago, I
> > created a framework that emitted KMS property changes only when they
> > actually needed changing. By review feedback (*), all that machinery was
> > dropped in a re-design, and today Weston always emits all KMS
> > properties it knows to program for a specific CRTC update including all
> > relevant planes and connectors.
> > 
> > (*) Why do we need to repeat the same state tracking that the kernel
> > does anyway, and also risk getting out of sync with the kernel due to
> > bugs which then become more difficult to diagnose. I guess (assumed)
> > kernel internals leaked to userspace. Oops.
> 
> The kernel does track the full state sure, but it doesn't generally
> go out of its way to figure out what specifically changed in that state.
> Doing so would be a lot of extra checks, and kinda less convenient to
> do inside the driver since at that point the state is already spread 
> all over the various structures. And the fact that those structures
> are a mismash of uapi and internal bits of state (and other metadata 
> for the single commit that really shouldn't be stored there) doesn't
> help matters. I did propose to split the state cleanly into pure uapi
> vs. internal stuff but that didn't gain any traction unfortunately.

Also, that's not how drivers are modelled, so even though we could
possibly figure out the entire state of the device, we don't have any
code for it because no one really needs to.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)