Re: [PATCH] arm64: Add ARM64_HAS_LSE2 CPU capability

[Mark Rutland <mark.rutland@arm.com>]

On Fri, Sep 06, 2024 at 08:20:19PM +0800, tiantao (H) wrote:
> 
> 在 2024/9/6 19:42, Mark Rutland 写道:
> > On Fri, Sep 06, 2024 at 06:58:19PM +0800, tiantao (H) wrote:
> > > 在 2024/9/6 17:44, Mark Rutland 写道:
> > > > On Fri, Sep 06, 2024 at 05:08:12PM +0800, Tian Tao wrote:
> > > I've come across a situation where the simplified code is as follows:
> > > 
> > >   long  address = (long) mmap(NULL,1024*1024*2,PROT_READ|PROT_WRITE,
> > > MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
> > > 
> > > long new_address = address + 9;
> > > 
> > >   long *p = (long*) new_address;
> > >   long v = -1;
> > > 
> > >   __atomic_store(p, &v, __ATOMIC_RELEASE);
> > Hold on; looking at the ARM ARM (ARM DDI 0487K.a), the example and the
> > patch are both bogus. NAK to this patch, explanation below.
> > 
> > Per section B2.2.1.1 "Changes to single-copy atomicity in Armv8.4", all of the
> > LSE2 relaxations on alignment require:
> > 
> > | all bytes being accessed are within a 16-byte quantity that is aligned
> > | to 16 bytes
> > 
> > In your example you perform an 8-byte access at an offset of 9 bytes,
> > which means the access is *not* contained within 16 bytes, and is *not*
> > guaranteed to be atomic. That code simply has to be fixed, the kernel
> > cannot magically make it safe.
> > 
> > Regardless of that, the nAA bit *only* causes an alignment fault for
> > accesses which cannot be atomic. If a CPU has LSE2 and SCTLR_ELx.nAA=0,
> > an unaligned access within 16 bytes (which would be atomic) does not
> > cause an alignment fault. That's pretty clear from the description of
> > nAA and the AArch64.UnalignedAccessFaults() pseudocode:
> 
> Sorry, this example is just for verifying nnA, it's not an example of a real
> scenario,
> 
> we have scenarios that don't require atomicity to be guaranteed, they just
> require that coredump doesn't occur when non-aligned

Please give a concrete explanation of such a scenario, with an
explanation of why atomicity is not required.

Mark.