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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0abe475a7b4b04758c03a9d19b228e86d95ac1dd.camel@ndufresne.ca>
Date:   Mon, 27 Jun 2022 09:54:34 -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

Le jeudi 23 juin 2022 à 11:33 +0200, Lucas Stach a écrit :
> > 
> > See for example on AMD/Intel hardware most of the engines can perfectly 
> > deal with cache coherent memory accesses. Only the display engines can't.
> > 
> > So on import time we can't even say if the access can be coherent and 
> > snoop the CPU cache or not because we don't know how the imported 
> > DMA-buf will be used later on.
> > 
> So for those mixed use cases, wouldn't it help to have something
> similar to the dma_sync in the DMA-buf API, so your scanout usage can
> tell the exporter that it's going to do non-snoop access and any dirty
> cache lines must be cleaned? Signaling this to the exporter would allow
> to skip the cache maintenance if the buffer is in CPU uncached memory,
> which again is a default case for the ARM SoC world.

Telling the exporter for every scan is unneeded overhead. If that information is
made available "properly", then tracking it in attach/detach is sufficient and
lightweight.

Nicolas