linux-kernel - Re: [PATCH] sparc32: Page align size in arch_dma

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: <20210914061705.GB26679@lst.de>
Date:   Tue, 14 Sep 2021 08:17:05 +0200
From:   Christoph Hellwig <hch@....de>
To:     Andreas Larsson <andreas@...sler.com>
Cc:     Christoph Hellwig <hch@....de>, David Miller <davem@...emloft.net>,
        sparclinux@...r.kernel.org, Sam Ravnborg <sam@...nborg.org>,
        linux-kernel@...r.kernel.org, software@...sler.com
Subject: Re: [PATCH] sparc32: Page align size in arch_dma_alloc

On Mon, Sep 13, 2021 at 03:18:38PM +0200, Andreas Larsson wrote:
>> Andreas - while I've got your attention:  I've been looking into fully
>> converting sparc32 to the generic DMA code.  Do you have any
>> documentation for the Leon cache handling in dma_make_coherent,
>> and more importantly how that applies to the dma coherent handling?
>> I could see how a flush might be required for the streaming DMA mappings,
>> that is mapping normal cached memory for I/O.  But for the coherent
>> allocations which can be accessed from the device and the cpu without
>> another DMA mapping call this seems really strange.
>
> As long as the area passed to arch_dma_free is mapped by
> arch_dma_allocate, I don't see why the call to dma_make_coherent in
> arch_dma_free should be needed. I am not sure if there are any current
> (or historical paths) where we nevertheless have a cacheable mapping
> when we reach arch_dma_free (or the historical pci32_free_coherent).

Note that the cacheable mapping in the kernel map still exists, but is
is not used for any access.

> The usual case for LEON systems is that cache snooping on the CPU side
> invalidates cache lines matching DMA that the CPU sees on the bus. Under
> the assumption that DMA accesses are seen on the processor bus, this is
> the reason for only flushing if snooping is not enabled in
> dma_make_coherent.

Thanks.  Can you take a look and test the two patches below on top of
your fix?  A git tree is also available here:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/sparc32-generic-dma

View attachment "0001-sparc32-remove-dma_make_coherent.patch" of type "text/x-patch" (2364 bytes)

View attachment "0002-sparc32-use-DMA_DIRECT_REMAP.patch" of type "text/x-patch" (3838 bytes)