linux-kernel - Re: [PATCH v8 0/6] drm: Add support for atomic async 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] [day] [month] [year] [list]

Date:   Fri, 17 Nov 2023 16:20:12 +0000
From:   Simon Ser <contact@...rsion.fr>
To:     André Almeida <andrealmeid@...lia.com>
Cc:     dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, kernel-dev@...lia.com,
        alexander.deucher@....com, christian.koenig@....com,
        pierre-eric.pelloux-prayer@....com,
        Rob Clark <robdclark@...il.com>,
        Pekka Paalanen <ppaalanen@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Daniel Stone <daniel@...ishbar.org>,
        'Marek Olšák' <maraeo@...il.com>,
        Dave Airlie <airlied@...il.com>,
        Michel Dänzer <michel.daenzer@...lbox.org>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v8 0/6] drm: Add support for atomic async page-flip

It seems like commits were re-ordered at some point. I think we need "drm:
introduce drm_mode_config.atomic_async_page_flip_not_supported" to come before
"drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits" because the latter
uses atomic_async_page_flip_not_supported. Similarly, "drm: Refuse to async flip
with atomic prop changes" should probably come before that same patch because
we don't want to have an intermediary state where we allow user-space to change
arbitrary properties. In general, commits should be constructed so that there
is no "broken state" in-between: each commit needs to build without errors and
not have transient bugs.

While reading this again, I think that now that we only allow primary FB_ID to
change, we don't need atomic_async_page_flip_not_supported anymore? In other
words, allowing async atomic commits on all drivers doesn't require anything
more than they support already, because the atomic codepath can't do anything
more than the legacy codepath.

With that in mind, I also wonder if the new cap is helpful. Since async atomic
commits can fail for pretty much any reason, user-space can just try and
fallback to something else. The cap could be useful to indicate whether async
atomic commits would always fail, but not sure how useful that is? I don't have
strong opinions either way.