linux-kernel - Re: [PATCH v7 0/3] drm: add explict fencing

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: <20161108124340.de4gqcuhkwn3uq2u@phenom.ffwll.local>
Date:   Tue, 8 Nov 2016 13:43:40 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Chris Wilson <chris@...is-wilson.co.uk>,
        Gustavo Padovan <gustavo@...ovan.org>,
        dri-devel@...ts.freedesktop.org, marcheu@...gle.com,
        Daniel Stone <daniels@...labora.com>, seanpaul@...gle.com,
        linux-kernel@...r.kernel.org, laurent.pinchart@...asonboard.com,
        Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
        John Harrison <John.C.Harrison@...el.com>, m.chehab@...sung.com
Subject: Re: [PATCH v7 0/3] drm: add explict fencing

On Tue, Nov 08, 2016 at 11:45:51AM +0000, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 08, 2016 at 10:35:08AM +0000, Chris Wilson wrote:
> > > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > > > From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
> > > > 
> > > > Hi,
> > > > 
> > > > This is yet another version of the DRM fences patches. Please refer
> > > > to the cover letter[1] in a previous version to check for more details.
> > > 
> > > Explicit fencing is not a superset of the implicit fences. The driver
> > > may be using implicit fences (on a reservation object) to serialise
> > > asynchronous operations wrt to each other (such as dispatching threads
> > > to flush cpu caches to memory, manipulating page tables and the like
> > > before the flip).  Since the user doesn't know about these operations,
> > > they are not included in the explicit fence they provide, at which point
> > > we can't trust their fence to the exclusion of the implicit fences...
> > 
> > My thoughts are that in atomic_check drivers just fill in the fence from
> > the reservation_object (i.e. the uapi implicit fencing part). If there's
> > any additional work that's queued up in ->prepare_fb then I guess the
> > driver needs to track that internally, but _only_ for kernel-internally
> > queued work.
> 
> That's not a trivial task to work out which of the fence contexts within
> the reservation object are required and which are to be replaced by the
> explicit fence, esp. when you have to consider external fences.

Hm, what kind of async kernel tasks are you thinking off? Atm I don't know
of anyone who does e.g. clflush through the gpu. And ttm bo placement
moves for display should be explicit enough that drivers will deal with
them correctly. At least that seems to have been the conclusion from the
long amdgpu thread.

> > The reason for that is that with explicit fencing we want to allow
> > userspace to overwrite any existing implicit fences that might hang
> > around.
> 
> I'm just suggesting the danger of that when userspace doesn't know
> everything and the current interfaces do not allow for userspace to know,
> we only tell userspace about its own action (more or less).

tools for fools, but yes userspace is expected to get this 100% right (for
any userspace-issued cs at least), and eat the fallout if it doesn't.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch