linux-kernel - Re: [PATCH 09/10] sh: don't allow non-coherent DMA for NOMMU

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

Message-ID: <20200628072446.GB16344@lst.de>
Date:   Sun, 28 Jun 2020 09:24:46 +0200
From:   Christoph Hellwig <hch@....de>
To:     Rob Landley <rob@...dley.net>
Cc:     Christoph Hellwig <hch@....de>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>, linux-sh@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/10] sh: don't allow non-coherent DMA for NOMMU

On Sat, Jun 27, 2020 at 08:01:17PM -0500, Rob Landley wrote:
> On 6/26/20 3:07 AM, Christoph Hellwig wrote:
> > The code handling non-coherent DMA depends on being able to remap code
> > as non-cached.  But that can't be done without an MMU, so using this
> > option on NOMMU builds is broken.
> 
> I'm working on a nommu j-core board that's doing DMA behind the OS's back at the
> moment, which I have a todo item to teach the kernel about. The DMA does not go
> through the cache, there's currently a cache flush before looking at the result
> instead.
> 
> How should this be wired up after your patch?

The problem with nommu and non-coherent dma is the dma_alloc_coherent
calls.  Most platforms with an mmu set a nocache bit through the page
tables (including sh), but that option obviously doesn't exist for
nommu.  Some hardware has an uncached window where access is uncached
automatically if access through specific kernel virtual addresses,
for that the architecture needs to impement the arch_dma_set_uncached
helper and select CONFIG_ARCH_HAS_DMA_SET_UNCACHED.  If that also
doesn't exist you'll need some sort of pool of always uncached
memory (set by the firmware or early startup code).  That currently
doesn't exist in generic code, but we have a bunch of architectures
implementing that in arch_dma_alloc.  I plan to have a common
implementation of the pool soon hopefully.

Streaming DMA just works if you reuse the existing
arch_sync_dma_for_device implementation.