Re: kern/58340: 64-bit atomic ops unusable for armv7: __HAVE_ATOMIC64_{OPS,LOADSTORE} confusion

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

The following reply was made to PR kern/58340; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58340: 64-bit atomic ops unusable for armv7:
 __HAVE_ATOMIC64_{OPS,LOADSTORE} confusion
Date: Tue, 18 Jun 2024 23:44:01 +0900

 Thank you very much for kind explanation!
 
 On 2024/06/18 12:05, Taylor R Campbell wrote:
 >> Date: Thu, 13 Jun 2024 02:14:45 +0000 (UTC)
 >> From: rokuyama.rk%gmail.com@localhost
 >>
 >> Check __HAVE_ATOMIC64_OPS, instead _LP64 for <sys/atomic.h>?
 >> But, do we still need __HAVE_ATOMIC64_LOADSTORE?
 > 
 > You need to make sure that the load and store instructions generated
 > by these macros are actually atomic.
 > 
 > It's possible that on earmv7 we can use ldrd and strd.  But:
 > 
 > (a) Do these macros actually result in that code being generated,
 >      reliably?  If not, you'll need to find a way to make sure they do
 >      before enabling __HAVE_ATOMIC64_LOADSTORE.
 > 
 > (b) Are ldrd and strd actually atomic with respect to other CPUs?
 >      Sounds like no, according to ARM DDI 0406C.d ID040418, p. A3-125:
 > 
 >          LDM, LDC, LDC2, LDRD, STM, STC, STC2, PUSH, POP, RFE, SRS,
 >          VLDM, VLDR, VSTM, and VSTR instructions are executed as a
 >          sequence of word-aligned word accesses.  Each 32-bit word
 >          access is guaranteed to be single-copy atomic.  The
 >          architecture does not require subsequences of two or more word
 >          accesses from the sequence to be single-copy atomic.
 > 
 > Some machines may technically support an atomic 64-bit load or store
 > via an expensive 64-bit compare-and-swap instruction or similar, or in
 > the case of armv7, a ldrexd/strexd loop.  But the point of
 > __HAVE_ATOMIC64_LOADSTORE is for fast paths to _avoid_ this.  So it's
 > only worthwhile if an _ordinary_ 64-bit load/store is actually atomic.
 
 Yeah, you're right. This (ldrexd/strexd loop) is what we do in
 common/lib/arch/arm/atomic.
 
 However, still, I have few questions:
 
 (1) Shouldn't we document things explicitly in, e.g., SIZE AND ALIGNMENT
 section in atomic_loadstore(9)?
 
 (2) Can't we provide 64-bit atomic-ops API for ILP32 platforms? If no,
 do you speak about something by which we don't provide such runtime
 routines with our libc?
 
 Thanks,
 rin