d7b0408934
xfrm_policy_lookup_bytype loops on seqcount mutex xfrm_policy_hash_generation
within an RCU read side critical section. Although ill advised, this is fine if
the loop is bounded.
xfrm_policy_hash_generation wraps mutex hash_resize_mutex, which is used to
serialize writers (xfrm_hash_resize, xfrm_hash_rebuild). This is fine too.
On PREEMPT_RT=y, the read_seqcount_begin call within xfrm_policy_lookup_bytype
emits a mutex lock/unlock for hash_resize_mutex. Mutex locking is fine, since
RCU read side critical sections are allowed to sleep with PREEMPT_RT.
xfrm_hash_resize can, however, block on synchronize_rcu while holding
hash_resize_mutex.
This leads to the following situation on PREEMPT_RT, where the writer is
blocked on RCU grace period expiry, while the reader is blocked on a lock held
by the writer:
Thead 1 (xfrm_hash_resize) Thread 2 (xfrm_policy_lookup_bytype)
rcu_read_lock();
mutex_lock(&hash_resize_mutex);
read_seqcount_begin(&xfrm_policy_hash_generation);
mutex_lock(&hash_resize_mutex); // block
xfrm_bydst_resize();
synchronize_rcu(); // block
<RCU stalls in xfrm_policy_lookup_bytype>
Move the read_seqcount_begin call outside of the RCU read side critical section,
and do an rcu_read_unlock/retry if we got stale data within the critical section.
On non-PREEMPT_RT, this shortens the time spent within RCU read side critical
section in case the seqcount needs a retry, and avoids unbounded looping.
Fixes:
|
||
---|---|---|
.. | ||
espintcp.c | ||
Kconfig | ||
Makefile | ||
xfrm_algo.c | ||
xfrm_compat.c | ||
xfrm_device.c | ||
xfrm_hash.c | ||
xfrm_hash.h | ||
xfrm_inout.h | ||
xfrm_input.c | ||
xfrm_interface.c | ||
xfrm_ipcomp.c | ||
xfrm_output.c | ||
xfrm_policy.c | ||
xfrm_proc.c | ||
xfrm_replay.c | ||
xfrm_state.c | ||
xfrm_sysctl.c | ||
xfrm_user.c |