linux-stable.git/kernel/futex/pi.c, branch v6.7

futex: Propagate flags into get_futex_key()

2023-09-21T17:22:09+00:00

Instead of only passing FLAGS_SHARED as a boolean, pass down flags as
a whole.

No functional change intended.

Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20230921105248.282857501@noisy.programming.kicks-ass.net

futex/pi: Fix recursive rt_mutex waiter state

2023-09-20T07:31:14+00:00

Some new assertions pointed out that the existing code has nested rt_mutex wait
state in the futex code.

Specifically, the futex_lock_pi() cancel case uses spin_lock() while there
still is a rt_waiter enqueued for this task, resulting in a state where there
are two waiters for the same task (and task_struct::pi_blocked_on gets
scrambled).

The reason to take hb->lock at this point is to avoid the wake_futex_pi()
EAGAIN case.

This happens when futex_top_waiter() and rt_mutex_top_waiter() state becomes
inconsistent. The current rules are such that this inconsistency will not be
observed.

Notably the case that needs to be avoided is where futex_lock_pi() and
futex_unlock_pi() interleave such that unlock will fail to observe a new
waiter.

*However* the case at hand is where a waiter is leaving, in this case the race
means a waiter that is going away is not observed -- which is harmless,
provided this race is explicitly handled.

This is a somewhat dangerous proposition because the converse race is not
observing a new waiter, which must absolutely not happen. But since the race is
valid this cannot be asserted.

Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Sebastian Andrzej Siewior 
Tested-by: Sebastian Andrzej Siewior 
Link: https://lkml.kernel.org/r/20230915151943.GD6743@noisy.programming.kicks-ass.net

locking/rtmutex: Use rt_mutex specific scheduler helpers

2023-09-20T07:31:13+00:00

Have rt_mutex use the rt_mutex specific scheduler helpers to avoid
recursion vs rtlock on the PI state.

[[ peterz: adapted to new names ]]

Reported-by: Crystal Wood 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20230908162254.999499-6-bigeasy@linutronix.de

futex: Remove a PREEMPT_RT_FULL reference.

2022-05-13T10:36:51+00:00

Earlier the PREEMPT_RT patch had a PREEMPT_RT_FULL and PREEMPT_RT_BASE
Kconfig option. The latter was a subset of the functionality that was
enabled with PREEMPT_RT_FULL and was mainly useful for debugging.

During the merging efforts the two Kconfig options were abandoned in the
v5.4.3-rt1 release and since then there is only PREEMPT_RT which enables
the full features set (as PREEMPT_RT_FULL did in earlier releases).

Replace the PREEMPT_RT_FULL reference with PREEMPT_RT.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Thomas Gleixner 
Reviewed-by: André Almeida 
Link: https://lore.kernel.org/r/YnvWUvq1vpqCfCU7@linutronix.de

futex: Split out PI futex

2021-10-07T11:51:09+00:00

Move the PI futex implementation into it's own file.

Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: André Almeida 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: André Almeida 
Link: https://lore.kernel.org/r/20210923171111.300673-10-andrealmeid@collabora.com