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: <3a653ab5-14d2-f61f-cb0a-cbeba93b4ac8@gaisler.com>
Date:   Mon, 13 Sep 2021 15:18:38 +0200
From:   Andreas Larsson <andreas@...sler.com>
To:     Christoph Hellwig <hch@....de>
Cc:     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 2021-09-09 08:07, Christoph Hellwig 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).

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.

-- 
Andreas Larsson