linux-kernel - Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

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>] [day] [month] [year] [list]

Message-ID: <4302638a-c33b-7355-5201-d3020f5b1525@igalia.com>
Date:   Tue, 27 Jun 2023 18:31:33 -0300
From:   André Almeida <andrealmeid@...lia.com>
To:     Marek Olšák <maraeo@...il.com>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        amd-gfx mailing list <amd-gfx@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@....com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Daniel Vetter <daniel@...ll.ch>,
        Michel Dänzer <michel.daenzer@...lbox.org>,
        Simon Ser <contact@...rsion.fr>,
        Timur Kristóf <timur.kristof@...il.com>,
        Pekka Paalanen <ppaalanen@...il.com>,
        Daniel Stone <daniel@...ishbar.org>,
        Rob Clark <robdclark@...il.com>,
        Samuel Pitoiset <samuel.pitoiset@...il.com>,
        kernel-dev@...lia.com, Bas Nieuwenhuizen <bas@...nieuwenhuizen.nl>,
        "Deucher, Alexander" <alexander.deucher@....com>,
        Pekka Paalanen <pekka.paalanen@...labora.com>,
        Dave Airlie <airlied@...il.com>,
        Christian König <christian.koenig@....com>
Subject: Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

Hi Marek,

Em 27/06/2023 15:57, Marek Olšák escreveu:
> On Tue, Jun 27, 2023, 09:23 André Almeida <andrealmeid@...lia.com 
> <mailto:andrealmeid@...lia.com>> wrote:
> 
>     +User Mode Driver
>     +----------------
>     +
>     +The UMD should check before submitting new commands to the KMD if
>     the device has
>     +been reset, and this can be checked more often if the UMD requires
>     it. After
>     +detecting a reset, UMD will then proceed to report it to the
>     application using
>     +the appropriate API error code, as explained in the section below about
>     +robustness.
> 
> 
> The UMD won't check the device status before every command submission 
> due to ioctl overhead. Instead, the KMD should skip command submission 
> and return an error that it was skipped.

I wrote like this because when reading the source code for 
vk::check_status()[0] and Gallium's si_flush_gfx_cs()[1], I was under 
the impression that UMD checks the reset status before every 
submission/flush.

Is your comment about of how things are currently implemented, or how 
they would ideally work? Either way I can apply your suggestion, I just 
want to make it clear.

[0] 
https://elixir.bootlin.com/mesa/mesa-23.1.3/source/src/vulkan/runtime/vk_device.h#L142
[1] 
https://elixir.bootlin.com/mesa/mesa-23.1.3/source/src/gallium/drivers/radeonsi/si_gfx_cs.c#L83

> 
> The only case where that won't be applicable is user queues where 
> drivers don't call into the kernel to submit work, but they do call into 
> the kernel to create a dma_fence. In that case, the call to create a 
> dma_fence can fail with an error.
> 
> Marek