linux-kernel - Re: [PATCH RFC 4/4] arm64/io: Add {__raw_read|__raw

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: <20251112140157.24ff4f2e@pumpkin>
Date: Wed, 12 Nov 2025 14:01:57 +0000
From: David Laight <david.laight.linux@...il.com>
To: Mark Rutland <mark.rutland@....com>
Cc: Chenghai Huang <huangchenghai2@...wei.com>, arnd@...db.de,
 catalin.marinas@....com, will@...nel.org, akpm@...ux-foundation.org,
 anshuman.khandual@....com, ryan.roberts@....com,
 andriy.shevchenko@...ux.intel.com, herbert@...dor.apana.org.au,
 linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-crypto@...r.kernel.org,
 linux-api@...r.kernel.org, fanghao11@...wei.com, shenyang39@...wei.com,
 liulongfang@...wei.com, qianweili@...wei.com
Subject: Re: [PATCH RFC 4/4] arm64/io: Add {__raw_read|__raw_write}128
 support

On Wed, 12 Nov 2025 12:28:01 +0000
Mark Rutland <mark.rutland@....com> wrote:

> On Wed, Nov 12, 2025 at 09:58:46AM +0800, Chenghai Huang wrote:
> > From: Weili Qian <qianweili@...wei.com>
> > 
> > Starting from ARMv8.4, stp and ldp instructions become atomic.  
> 
> That's not true for accesses to Device memory types.
> 
> Per ARM DDI 0487, L.b, section B2.2.1.1 ("Changes to single-copy atomicity in
> Armv8.4"):
> 
>   If FEAT_LSE2 is implemented, LDP, LDNP, and STP instructions that load
>   or store two 64-bit registers are single-copy atomic when all of the
>   following conditions are true:
>   • The overall memory access is aligned to 16 bytes.
>   • Accesses are to Inner Write-Back, Outer Write-Back Normal cacheable memory.
> 
> IIUC when used for Device memory types, those can be split, and a part
> of the access could be replayed multiple times (e.g. due to an
> intetrupt).

That can't be right.
IO accesses can reference hardware FIFO so must only happen once.
(Or is 'Device memory' something different from 'Device register'?
I'm also not sure that the bus cycles could get split by an interrupt,
that would require a mid-instruction interrupt - very unlikely.
Interleaving is most likely to come from another cpu.

More interesting would be whether the instructions generate a single
PCIe TLP? (perhaps even only most of the time.)
PCIe reads are high latency, anything that can be done to increase the
size of the TLP improves PIO throughput massively.

	David

> 
> I don't think we can add this generally. It is not atomic, and not
> generally safe.
> 
> Mark.
...