summaryrefslogtreecommitdiffstats
path: root/Makefile
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2019-04-08 14:23:17 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-05-10 17:53:15 +0200
commitd5d05286b6ba27ff4b29f9bf2ba99c716a31c307 (patch)
treeff4b3848ad3fb24a27fc30199e47a49056697f1c /Makefile
parentd2045151af9da38178c6e38581d94f239dc840e5 (diff)
downloadlinux-stable-d5d05286b6ba27ff4b29f9bf2ba99c716a31c307.tar.gz
linux-stable-d5d05286b6ba27ff4b29f9bf2ba99c716a31c307.tar.bz2
linux-stable-d5d05286b6ba27ff4b29f9bf2ba99c716a31c307.zip
arm64: futex: Bound number of LDXR/STXR loops in FUTEX_WAKE_OP
commit 03110a5cb2161690ae5ac04994d47ed0cd6cef75 upstream. Our futex implementation makes use of LDXR/STXR loops to perform atomic updates to user memory from atomic context. This can lead to latency problems if we end up spinning around the LL/SC sequence at the expense of doing something useful. Rework our futex atomic operations so that we return -EAGAIN if we fail to update the futex word after 128 attempts. The core futex code will reschedule if necessary and we'll try again later. Cc: <stable@kernel.org> Fixes: 6170a97460db ("arm64: Atomic operations") Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions