linux-kernel - Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark

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: <1be05746-9deb-49cb-b106-71b2db8318cd@app.fastmail.com>
Date:   Fri, 31 Mar 2023 16:06:37 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Russell King" <linux@...linux.org.uk>,
        "Arnd Bergmann" <arnd@...nel.org>
Cc:     linux-kernel@...r.kernel.org, "Vineet Gupta" <vgupta@...nel.org>,
        "Neil Armstrong" <neil.armstrong@...aro.org>,
        "Linus Walleij" <linus.walleij@...aro.org>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Will Deacon" <will@...nel.org>, guoren <guoren@...nel.org>,
        "Brian Cain" <bcain@...cinc.com>,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>,
        "Michal Simek" <monstr@...str.eu>,
        "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
        "Dinh Nguyen" <dinguyen@...nel.org>,
        "Stafford Horne" <shorne@...il.com>,
        "Helge Deller" <deller@....de>,
        "Michael Ellerman" <mpe@...erman.id.au>,
        "Christophe Leroy" <christophe.leroy@...roup.eu>,
        "Paul Walmsley" <paul.walmsley@...ive.com>,
        "Palmer Dabbelt" <palmer@...belt.com>,
        "Rich Felker" <dalias@...c.org>,
        "John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>,
        "David S . Miller" <davem@...emloft.net>,
        "Max Filippov" <jcmvbkbc@...il.com>,
        "Christoph Hellwig" <hch@....de>,
        "Robin Murphy" <robin.murphy@....com>,
        "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>,
        "Conor.Dooley" <conor.dooley@...rochip.com>,
        linux-snps-arc@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org,
        "linux-oxnas@...ups.io" <linux-oxnas@...ups.io>,
        "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
        linux-hexagon@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
        linux-mips@...r.kernel.org,
        "linux-openrisc@...r.kernel.org" <linux-openrisc@...r.kernel.org>,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-riscv@...ts.infradead.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org
Subject: Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper

On Mon, Mar 27, 2023, at 17:01, Russell King (Oracle) wrote:
> On Mon, Mar 27, 2023 at 02:13:16PM +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@...db.de>
>> 
>> The arm version of the arch_sync_dma_for_cpu() function annotates pages as
>> PG_dcache_clean after a DMA, but no other architecture does this here.
>
> ... because this is an arm32 specific feature. Generically, it's
> PG_arch_1, which is a page flag free for architecture use. On arm32
> we decided to use this to mark whether we can skip dcache writebacks
> when establishing a PTE - and thus it was decided to call it
> PG_dcache_clean to reflect how arm32 decided to use that bit.
>
> This isn't just a DMA thing, there are other places that we update
> the bit, such as flush_dcache_page() and copy_user_highpage().
>
> So thinking that the arm32 PG_dcache_clean is something for DMA is
> actually wrong.
>
> Other architectures are free to do their own other optimisations
> using that bit, and their implementations may be DMA-centric.

The flag is used the same way on most architectures, though some
use the opposite polarity and call it PG_dcache_dirty. The only
other architecture that uses it for DMA is ia64, with the difference
being that this also marks the page as clean even for coherent
DMA, not just when doing a flush as part of noncoherent DMA.

Based on Robin's reply it sounds that this is not a valid assumption
on Arm, if a coherent DMA can target a dirty dcache line without
cleaning it.

     Arnd