locking/futex: Allow low-level atomic operations to return -EAGAIN
authorWill Deacon <will.deacon@arm.com>
Thu, 28 Feb 2019 11:58:08 +0000 (11:58 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 10 May 2019 15:54:11 +0000 (17:54 +0200)
commit0f4ef8fb1dae3cf2c1017fb46b9d14b1de2e501a
tree2db3dcb136d2a40046dde3164b5ce7cf1561f858
parent6fee39874d1ff57a280c420f69195969594aabf5
locking/futex: Allow low-level atomic operations to return -EAGAIN

commit 6b4f4bc9cb22875f97023984a625386f0c7cc1c0 upstream.

Some futex() operations, including FUTEX_WAKE_OP, require the kernel to
perform an atomic read-modify-write of the futex word via the userspace
mapping. These operations are implemented by each architecture in
arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic(), which
are called in atomic context with the relevant hash bucket locks held.

Although these routines may return -EFAULT in response to a page fault
generated when accessing userspace, they are expected to succeed (i.e.
return 0) in all other cases. This poses a problem for architectures
that do not provide bounded forward progress guarantees or fairness of
contended atomic operations and can lead to starvation in some cases.

In these problematic scenarios, we must return back to the core futex
code so that we can drop the hash bucket locks and reschedule if
necessary, much like we do in the case of a page fault.

Allow architectures to return -EAGAIN from their implementations of
arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic(), which
will cause the core futex code to reschedule if necessary and return
back to the architecture code later on.

Cc: <stable@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel/futex.c