linux-kernel - Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

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: <20190124091316.GA22796@infradead.org>
Date:   Thu, 24 Jan 2019 01:13:16 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Alex Deucher <alexdeucher@...il.com>,
        Michel Dänzer <michel@...nzer.net>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Will Deacon <will.deacon@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>,
        David Airlie <airlied@...ux.ie>, Huang Rui <ray.huang@....com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Junwei Zhang <Jerry.Zhang@....com>,
        Alex Deucher <alexander.deucher@....com>,
        Sean Paul <sean@...rly.run>,
        Christian Koenig <christian.koenig@....com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH] drm: disable WC optimization for cache coherent
 devices on non-x86

On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
> But my concern is that it seems likely that non-cache coherent
> implementations are relying on this hack as well. There must be a
> reason that this hack is only disabled for PowerPC platforms if they
> are cache coherent, for instance, and I suspect that that reason is
> that the hack is the only thing ensuring that the CPU mapping
> attributes match the device ones used for these buffers (the vmap()ed
> ones), whereas the rings and other consistent data structures are
> using the DMA API as intended, and thus getting uncached attributes in
> the correct way.

Dave, who added that commit is on Cc together with just about everyone
involved in the review chain.  Based on the previous explanation
that idea what we might want an uncached mapping for some non-coherent
architectures for this to work at all makes sense, but then again
the way to create those mappings is entirely architecture specific,
and also need a cache flushing before creating the mapping to work
properly.  So my working theory is that this code never properly
worked on architectures without DMA coherent for PCIe at all, but
I'd love to be corrected by concrete examples including an explanation
of how it actually ends up working.