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>
Sat, 11 May 2019 05:49:56 +0000 (07:49 +0200)
commit325d0a18d3ff0d0392dcbb624f0818b7dade2420
tree2384c2570b185e2a8e58f9c24eb386f01a9fa6d9
parent3ae39e99e5395bee9dfa6796c2e2f125d96d0096
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