linux-kernel - Re: DMA-buf and uncached system memory

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

Message-ID: <36eef859d63640b4456360e17383635644703e3d.camel@ndufresne.ca>
Date:   Mon, 27 Jun 2022 09:51:24 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Lucas Stach <l.stach@...gutronix.de>,
        Christian König <christian.koenig@....com>,
        Pekka Paalanen <ppaalanen@...il.com>
Cc:     "Sharma, Shashank" <Shashank.Sharma@....com>,
        lkml <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linaro-mm-sig@...ts.linaro.org,
        Sumit Semwal <sumit.semwal@...aro.org>,
        linux-media <linux-media@...r.kernel.org>
Subject: Re: DMA-buf and uncached system memory

Hi,

Le jeudi 23 juin 2022 à 10:58 +0200, Lucas Stach a écrit :
> > > In the DMA API keeping things mapped is also a valid use-case, but then
> > > you need to do explicit domain transfers via the dma_sync_* family,
> > > which DMA-buf has not inherited. Again those sync are no-ops on cache
> > > coherent architectures, but do any necessary cache maintenance on non
> > > coherent arches.
> > 
> > Correct, yes. Coherency is mandatory for DMA-buf, you can't use 
> > dma_sync_* on it when you are the importer.
> > 
> > The exporter could of course make use of that because he is the owner of 
> > the buffer.
> 
> In the example given here with UVC video, you don't know that the
> buffer will be exported and needs to be coherent without
> synchronization points, due to the mapping cache at the DRM side. So
> V4L2 naturally allocates the buffers from CPU cached memory. If the
> expectation is that those buffers are device coherent without relying
> on the map/unmap_attachment calls, then V4L2 needs to always
> synchronize caches on DQBUF when the  buffer is allocated from CPU
> cached memory and a single DMA-buf attachment exists. And while writing
> this I realize that this is probably exactly what V4L2 should do...

I'm not sure we are making any progress here. Doing so will just regress
performance of coherent devices used to render UVC video feeds. In fact, they
are all coherent except the display controller (on Intel). What my colleague was
suggesting me to try (with the expectation that some adaptation will be needed,
perhaps new signalling flags), is to read the dma_coherency_mask values on the
devices that calls attach() and adapt v4l2 exporter accordingly.

Its likely wrong as-is, not intended to be used for that, but the value is that
it tries to fix the problem, unlike what I'm reading here.

Nicolas