<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arm64/include/asm/spinlock.h, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-05-30T05:50:25Z</updated>
<entry>
<title>arm64: spinlock: Fix theoretical trylock() A-B-A with LSE atomics</title>
<updated>2018-05-30T05:50:25Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2018-01-31T12:12:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0675ec13c63f9eb918342b63614738767ef079a3'/>
<id>urn:sha1:0675ec13c63f9eb918342b63614738767ef079a3</id>
<content type='text'>
[ Upstream commit 202fb4ef81e3ec765c23bd1e6746a5c25b797d0e ]

If the spinlock "next" ticket wraps around between the initial LDR
and the cmpxchg in the LSE version of spin_trylock, then we can erroneously
think that we have successfuly acquired the lock because we only check
whether the next ticket return by the cmpxchg is equal to the owner ticket
in our updated lock word.

This patch fixes the issue by performing a full 32-bit check of the lock
word when trying to determine whether or not the CASA instruction updated
memory.

Reported-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux</title>
<updated>2016-10-03T15:58:35Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2016-10-03T15:58:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7af8a0f8088831428051976cb06cc1e450f8bab5'/>
<id>urn:sha1:7af8a0f8088831428051976cb06cc1e450f8bab5</id>
<content type='text'>
Pull arm64 updates from Will Deacon:
 "It's a bit all over the place this time with no "killer feature" to
  speak of.  Support for mismatched cache line sizes should help people
  seeing whacky JIT failures on some SoCs, and the big.LITTLE perf
  updates have been a long time coming, but a lot of the changes here
  are cleanups.

  We stray outside arch/arm64 in a few areas: the arch/arm/ arch_timer
  workaround is acked by Russell, the DT/OF bits are acked by Rob, the
  arch_timer clocksource changes acked by Marc, CPU hotplug by tglx and
  jump_label by Peter (all CC'd).

  Summary:

   - Support for execute-only page permissions
   - Support for hibernate and DEBUG_PAGEALLOC
   - Support for heterogeneous systems with mismatches cache line sizes
   - Errata workarounds (A53 843419 update and QorIQ A-008585 timer bug)
   - arm64 PMU perf updates, including cpumasks for heterogeneous systems
   - Set UTS_MACHINE for building rpm packages
   - Yet another head.S tidy-up
   - Some cleanups and refactoring, particularly in the NUMA code
   - Lots of random, non-critical fixes across the board"

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (100 commits)
  arm64: tlbflush.h: add __tlbi() macro
  arm64: Kconfig: remove SMP dependence for NUMA
  arm64: Kconfig: select OF/ACPI_NUMA under NUMA config
  arm64: fix dump_backtrace/unwind_frame with NULL tsk
  arm/arm64: arch_timer: Use archdata to indicate vdso suitability
  arm64: arch_timer: Work around QorIQ Erratum A-008585
  arm64: arch_timer: Add device tree binding for A-008585 erratum
  arm64: Correctly bounds check virt_addr_valid
  arm64: migrate exception table users off module.h and onto extable.h
  arm64: pmu: Hoist pmu platform device name
  arm64: pmu: Probe default hw/cache counters
  arm64: pmu: add fallback probe table
  MAINTAINERS: Update ARM PMU PROFILING AND DEBUGGING entry
  arm64: Improve kprobes test for atomic sequence
  arm64/kvm: use alternative auto-nop
  arm64: use alternative auto-nop
  arm64: alternative: add auto-nop infrastructure
  arm64: lse: convert lse alternatives NOP padding to use __nops
  arm64: barriers: introduce nops and __nops macros for NOP sequences
  arm64: sysreg: replace open-coded mrs_s/msr_s with {read,write}_sysreg_s
  ...
</content>
</entry>
<entry>
<title>arm64: lse: convert lse alternatives NOP padding to use __nops</title>
<updated>2016-09-09T17:12:34Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2016-09-06T15:42:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=05492f2fd87d0a2e6a626bf8fe002c9a11941950'/>
<id>urn:sha1:05492f2fd87d0a2e6a626bf8fe002c9a11941950</id>
<content type='text'>
The LSE atomics are implemented using alternative code sequences of
different lengths, and explicit NOP padding is used to ensure the
patching works correctly.

This patch converts the bulk of the LSE code over to using the __nops
macro, which makes it slightly clearer as to what is going on and also
consolidates all of the padding at the end of the various sequences.

Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: spinlocks: implement smp_mb__before_spinlock() as smp_mb()</title>
<updated>2016-09-09T11:33:48Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2016-09-05T10:56:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=872c63fbf9e153146b07f0cece4da0d70b283eeb'/>
<id>urn:sha1:872c63fbf9e153146b07f0cece4da0d70b283eeb</id>
<content type='text'>
smp_mb__before_spinlock() is intended to upgrade a spin_lock() operation
to a full barrier, such that prior stores are ordered with respect to
loads and stores occuring inside the critical section.

Unfortunately, the core code defines the barrier as smp_wmb(), which
is insufficient to provide the required ordering guarantees when used in
conjunction with our load-acquire-based spinlock implementation.

This patch overrides the arm64 definition of smp_mb__before_spinlock()
to map to a full smp_mb().

Cc: &lt;stable@vger.kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Reported-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: spinlock: Ensure forward-progress in spin_unlock_wait</title>
<updated>2016-06-15T10:23:14Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2016-06-02T17:40:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c56bdcac153e60d96a619a59c7981f2a78cba598'/>
<id>urn:sha1:c56bdcac153e60d96a619a59c7981f2a78cba598</id>
<content type='text'>
Rather than wait until we observe the lock being free (which might never
happen), we can also return from spin_unlock_wait if we observe that the
lock is now held by somebody else, which implies that it was unlocked
but we just missed seeing it in that state.

Furthermore, in such a scenario there is no longer a need to write back
the value that we loaded, since we know that there has been a lock
hand-off, which is sufficient to publish any stores prior to the
unlock_wait because the ARm architecture ensures that a Store-Release
instruction is multi-copy atomic when observed by a Load-Acquire
instruction.

The litmus test is something like:

AArch64
{
0:X1=x; 0:X3=y;
1:X1=y;
2:X1=y; 2:X3=x;
}
 P0          | P1           | P2           ;
 MOV W0,#1   | MOV W0,#1    | LDAR W0,[X1] ;
 STR W0,[X1] | STLR W0,[X1] | LDR W2,[X3]  ;
 DMB SY      |              |              ;
 LDR W2,[X3] |              |              ;
exists
(0:X2=0 /\ 2:X0=1 /\ 2:X2=0)

where P0 is doing spin_unlock_wait, P1 is doing spin_unlock and P2 is
doing spin_lock.

Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: spinlock: fix spin_unlock_wait for LSE atomics</title>
<updated>2016-06-15T08:51:36Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2016-06-08T14:10:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3a5facd09da848193f5bcb0dea098a298bc1a29d'/>
<id>urn:sha1:3a5facd09da848193f5bcb0dea098a298bc1a29d</id>
<content type='text'>
Commit d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against
concurrent lockers") fixed spin_unlock_wait for LL/SC-based atomics under
the premise that the LSE atomics (in particular, the LDADDA instruction)
are indivisible.

Unfortunately, these instructions are only indivisible when used with the
-AL (full ordering) suffix and, consequently, the same issue can
theoretically be observed with LSE atomics, where a later (in program
order) load can be speculated before the write portion of the atomic
operation.

This patch fixes the issue by performing a CAS of the lock once we've
established that it's unlocked, in much the same way as the LL/SC code.

Fixes: d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against concurrent lockers")
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: spinlock: order spin_{is_locked,unlock_wait} against local locks</title>
<updated>2016-06-15T08:51:35Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2016-06-02T14:27:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=38b850a73034f075c4088e7511b36ebbef9dce00'/>
<id>urn:sha1:38b850a73034f075c4088e7511b36ebbef9dce00</id>
<content type='text'>
spin_is_locked has grown two very different use-cases:

(1) [The sane case] API functions may require a certain lock to be held
    by the caller and can therefore use spin_is_locked as part of an
    assert statement in order to verify that the lock is indeed held.
    For example, usage of assert_spin_locked.

(2) [The insane case] There are two locks, where a CPU takes one of the
    locks and then checks whether or not the other one is held before
    accessing some shared state. For example, the "optimized locking" in
    ipc/sem.c.

In the latter case, the sequence looks like:

  spin_lock(&amp;sem-&gt;lock);
  if (!spin_is_locked(&amp;sma-&gt;sem_perm.lock))
    /* Access shared state */

and requires that the spin_is_locked check is ordered after taking the
sem-&gt;lock. Unfortunately, since our spinlocks are implemented using a
LDAXR/STXR sequence, the read of &amp;sma-&gt;sem_perm.lock can be speculated
before the STXR and consequently return a stale value.

Whilst this hasn't been seen to cause issues in practice, PowerPC fixed
the same issue in 51d7d5205d33 ("powerpc: Add smp_mb() to
arch_spin_is_locked()") and, although we did something similar for
spin_unlock_wait in d86b8da04dfa ("arm64: spinlock: serialise
spin_unlock_wait against concurrent lockers") that doesn't actually take
care of ordering against local acquisition of a different lock.

This patch adds an smp_mb() to the start of our arch_spin_is_locked and
arch_spin_unlock_wait routines to ensure that the lock value is always
loaded after any other locks have been taken by the current CPU.

Reported-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: spinlock: serialise spin_unlock_wait against concurrent lockers</title>
<updated>2015-12-03T19:37:59Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2015-11-19T17:48:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d86b8da04dfa4771a68bdbad6c424d40f22f0d14'/>
<id>urn:sha1:d86b8da04dfa4771a68bdbad6c424d40f22f0d14</id>
<content type='text'>
Boqun Feng reported a rather nasty ordering issue with spin_unlock_wait
on architectures implementing spin_lock with LL/SC sequences and acquire
semantics:

 | CPU 1                   CPU 2                     CPU 3
 | ==================      ====================      ==============
 |                                                   spin_unlock(&amp;lock);
 |                         spin_lock(&amp;lock):
 |                           r1 = *lock; // r1 == 0;
 |                         o = READ_ONCE(object); // reordered here
 | object = NULL;
 | smp_mb();
 | spin_unlock_wait(&amp;lock);
 |                           *lock = 1;
 | smp_mb();
 | o-&gt;dead = true;
 |                         if (o) // true
 |                           BUG_ON(o-&gt;dead); // true!!

The crux of the problem is that spin_unlock_wait(&amp;lock) can return on
CPU 1 whilst CPU 2 is in the process of taking the lock. This can be
resolved by upgrading spin_unlock_wait to a LOCK operation, forcing it
to serialise against a concurrent locker and giving it acquire semantics
in the process (although it is not at all clear whether this is needed -
different callers seem to assume different things about the barrier
semantics and architectures are similarly disjoint in their
implementations of the macro).

This patch implements spin_unlock_wait using an LL/SC sequence with
acquire semantics on arm64. For v8.1 systems with the LSE atomics, the
exclusive writeback is omitted, since the spin_lock operation is
indivisible and no intermediate state can be observed.

Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: spinlock: fix ll/sc unlock on big-endian systems</title>
<updated>2015-07-28T13:48:00Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2015-07-28T13:48:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c1d7cd228b4b46eca1dbd9bb2c6053f477a1a6ff'/>
<id>urn:sha1:c1d7cd228b4b46eca1dbd9bb2c6053f477a1a6ff</id>
<content type='text'>
When unlocking a spinlock, we perform a read-modify-write on the owner
ticket in order to increment it and store it back with release
semantics.

In the LL/SC case, we load the 16-bit ticket using a 32-bit load and
therefore store back the wrong halfword on a big-endian system,
corrupting the lock after the first unlock and killing the system dead.

This patch fixes the unlock code to use 16-bit accessors consistently.

Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: locks: patch in lse instructions when supported by the CPU</title>
<updated>2015-07-27T14:28:51Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2015-02-10T03:03:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=81bb5c6420635dfd058c210bd342c29c95ccd145'/>
<id>urn:sha1:81bb5c6420635dfd058c210bd342c29c95ccd145</id>
<content type='text'>
On CPUs which support the LSE atomic instructions introduced in ARMv8.1,
it makes sense to use them in preference to ll/sc sequences.

This patch introduces runtime patching of our locking functions so that
LSE atomic instructions are used for spinlocks and rwlocks.

Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
</feed>
