linux-kernel - Re: [PATCH] Add io_sync stubs to generic IO memcpy/memset

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: <308d30b7-acdb-43ec-bb27-7912a5351bcc@app.fastmail.com>
Date: Mon, 27 Jan 2025 16:48:18 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Julian Vetter" <julian@...er-limits.org>,
 "Andrew Morton" <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add io_sync stubs to generic IO memcpy/memset

On Mon, Jan 27, 2025, at 15:11, Julian Vetter wrote:
> On 1/27/25 11:27, Arnd Bergmann wrote:
>> On Mon, Jan 27, 2025, at 11:04, Julian Vetter wrote:
>
> Thank you for your quick reply. You're right, I was just going with the
> naming used in the powerpc arch which has an io_sync define. I'm now
> wondering if we can't simply use the read{l,q}/write{l,q} functions
> (instead of the __raw_xxx version), there are already calls to __io_br
> before and__io_ar after each read (and write). But this might have
> performance implications on some architectures, depending what it
> resolves to.
>
> Otherwise I propose renaming the __pre_io_sync and __post_io_sync into a
> single __io_mbr which is called before and after each loop. Looking at 
> PowerPC and SuperH, both of them could be consolidated into the generic 
> IO memcpy code when adding this. What do you think?

Having barriers between the accesses would be very expensive, and
prevent the write-combining and prefetching that can otherwise happen
(depending on mapping flags).

I suspect that the powerpc variant got this wrong for historic
reasons, but that's hard to tell now. The ppc32 variant didn't
have barriers at all originally, it was just memcpy/memset
before it got combined with ppc64 into arch/powerpc.

> The existing ones, especially __io_br unfortunately don't resolve to the 
> right define on these architectures. The __io_ar and __io_br resolve to 
> the right mb() on SuperH and PowerPC as well, but this would again have 
> implications on other architectures.

The barriers in the sh functions seem arbitrary, and I would
expect them to be wrong.


      ARnd