linux-kernel - Re: [PATCH v2 0/4] Consolidate IO memcpy functions

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: <601b10c8-148e-4d61-b6b7-5b473842927a@app.fastmail.com>
Date: Tue, 10 Sep 2024 16:07:20 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Julian Vetter" <jvetter@...rayinc.com>,
 "Catalin Marinas" <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>,
 guoren <guoren@...nel.org>, "Huacai Chen" <chenhuacai@...nel.org>,
 "WANG Xuerui" <kernel@...0n.name>,
 "Andrew Morton" <akpm@...ux-foundation.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
 loongarch@...ts.linux.dev, "Yann Sionneau" <ysionneau@...rayinc.com>
Subject: Re: [PATCH v2 0/4] Consolidate IO memcpy functions

On Mon, Sep 9, 2024, at 13:31, Julian Vetter wrote:
> Thank you for your feedback Arnd. In regards to the filename, etc. I
> went with the first route and created a new file called io_copy.c.
> Although, I'm not sure if it's a good idea to create yet another file
> that serves a limited purpose. But I'm a bit afraid to add the
> functions to iomap_copy.c because there is no common consus in the
> architecture code about memcpy_{from,to}io. Some specify it with
> _memcpy_xx, some directly with memcpy_xx, and another bunch uses
> __memcpy_xx.

Just for clarification: the idea in that file is to have a
generic implementation and use that on all architectures that
do not define their own, hence the "#define __iowrite32_copy
__iowrite32_copy" for the three that do. The exact same method
would clearly work for memcpy_fromio().

At the moment, there are 13 architectures that define a custom
memcpy_fromio/memcpy_toio/memset_io, and nine that rely on the
fallback using memcpy()/memset() in include/asm-generic/io.h.

What we could do here is to first change the fallback
implementation in asm-generic/io.h to your new generic
version and then remove the three extra copies.

> So, if we want to merge it with iomap_copy.c, I would need
> to export the __memcpy_xx symbols for all architectures that don't want
> to use the "generic" memcpy_xx functions for now or rename their given
> implementation to __memcpy_xx, right? But if you think it's better to
> merge the two, I will have another look and modify the code for all
> remaining architectures as well.

No, this would not be necessary: the architectures that
already have a custom memcpy_fromio() etc can just keep
using the same one. Cleaning those up is something we
can do later, in which case most of them would probably
converge on the generic version.

     Arnd