2019-05-19 15:08:55 +03:00
// SPDX-License-Identifier: GPL-2.0-only
2006-06-27 13:54:53 +04:00
/*
* RT - Mutexes : simple blocking mutual exclusion locks with PI support
*
* started by Ingo Molnar and Thomas Gleixner .
*
* Copyright ( C ) 2004 - 2006 Red Hat , Inc . , Ingo Molnar < mingo @ redhat . com >
* Copyright ( C ) 2005 - 2006 Timesys Corp . , Thomas Gleixner < tglx @ timesys . com >
* Copyright ( C ) 2005 Kihon Technologies Inc . , Steven Rostedt
* Copyright ( C ) 2006 Esben Nielsen
2021-08-16 00:29:25 +03:00
* Adaptive Spinlocks :
* Copyright ( C ) 2008 Novell , Inc . , Gregory Haskins , Sven Dietrich ,
* and Peter Morreale ,
* Adaptive Spinlocks simplification :
* Copyright ( C ) 2008 Red Hat , Inc . , Steven Rostedt < srostedt @ redhat . com >
2006-07-30 14:04:03 +04:00
*
2019-04-10 14:32:41 +03:00
* See Documentation / locking / rt - mutex - design . rst for details .
2006-06-27 13:54:53 +04:00
*/
2021-08-16 00:27:57 +03:00
# include <linux/sched.h>
# include <linux/sched/debug.h>
# include <linux/sched/deadline.h>
2017-02-02 21:15:33 +03:00
# include <linux/sched/signal.h>
2013-02-07 19:47:07 +04:00
# include <linux/sched/rt.h>
2017-02-01 18:36:40 +03:00
# include <linux/sched/wake_q.h>
2021-08-16 00:28:58 +03:00
# include <linux/ww_mutex.h>
2006-06-27 13:54:53 +04:00
2022-03-22 21:57:09 +03:00
# include <trace/events/lock.h>
2006-06-27 13:54:53 +04:00
# include "rtmutex_common.h"
2021-08-16 00:28:58 +03:00
# ifndef WW_RT
# define build_ww_mutex() (false)
# define ww_container_of(rtm) NULL
static inline int __ww_mutex_add_waiter ( struct rt_mutex_waiter * waiter ,
struct rt_mutex * lock ,
struct ww_acquire_ctx * ww_ctx )
{
return 0 ;
}
static inline void __ww_mutex_check_waiters ( struct rt_mutex * lock ,
struct ww_acquire_ctx * ww_ctx )
{
}
static inline void ww_mutex_lock_acquired ( struct ww_mutex * lock ,
struct ww_acquire_ctx * ww_ctx )
{
}
static inline int __ww_mutex_check_kill ( struct rt_mutex * lock ,
struct rt_mutex_waiter * waiter ,
struct ww_acquire_ctx * ww_ctx )
{
return 0 ;
}
# else
# define build_ww_mutex() (true)
# define ww_container_of(rtm) container_of(rtm, struct ww_mutex, base)
# include "ww_mutex.h"
# endif
2006-06-27 13:54:53 +04:00
/*
* lock - > owner state tracking :
*
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
* lock - > owner holds the task_struct pointer of the owner . Bit 0
* is used to keep track of the " lock has waiters " state .
2006-06-27 13:54:53 +04:00
*
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
* owner bit0
* NULL 0 lock is free ( fast acquire possible )
* NULL 1 lock is free and has waiters and the top waiter
* is going to take the lock *
* taskpointer 0 lock is held ( fast release possible )
* taskpointer 1 lock is held and has waiters * *
2006-06-27 13:54:53 +04:00
*
* The fast atomic compare exchange based acquire and release is only
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
* possible when bit 0 of lock - > owner is 0.
*
* ( * ) It also can be a transitional state when grabbing the lock
* with - > wait_lock is held . To prevent any fast path cmpxchg to the lock ,
* we need to set the bit0 before looking at the lock , and the owner may be
* NULL in this small time , hence this can be a transitional state .
2006-06-27 13:54:53 +04:00
*
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
* ( * * ) There is a small time when bit 0 is set but there are no
* waiters . This can happen when grabbing the lock in the slow path .
* To prevent a cmpxchg of the owner releasing the lock , we need to
* set this bit before looking at the lock .
2006-06-27 13:54:53 +04:00
*/
2022-12-02 13:02:23 +03:00
static __always_inline struct task_struct *
rt_mutex_owner_encode ( struct rt_mutex_base * lock , struct task_struct * owner )
2006-06-27 13:54:53 +04:00
{
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
unsigned long val = ( unsigned long ) owner ;
2006-06-27 13:54:53 +04:00
if ( rt_mutex_has_waiters ( lock ) )
val | = RT_MUTEX_HAS_WAITERS ;
2022-12-02 13:02:23 +03:00
return ( struct task_struct * ) val ;
}
static __always_inline void
rt_mutex_set_owner ( struct rt_mutex_base * lock , struct task_struct * owner )
{
/*
* lock - > wait_lock is held but explicit acquire semantics are needed
* for a new lock owner so WRITE_ONCE is insufficient .
*/
xchg_acquire ( & lock - > owner , rt_mutex_owner_encode ( lock , owner ) ) ;
}
static __always_inline void rt_mutex_clear_owner ( struct rt_mutex_base * lock )
{
/* lock->wait_lock is held so the unlock provides release semantics. */
WRITE_ONCE ( lock - > owner , rt_mutex_owner_encode ( lock , NULL ) ) ;
2006-06-27 13:54:53 +04:00
}
2021-08-16 00:27:58 +03:00
static __always_inline void clear_rt_mutex_waiters ( struct rt_mutex_base * lock )
2006-06-27 13:54:53 +04:00
{
lock - > owner = ( struct task_struct * )
( ( unsigned long ) lock - > owner & ~ RT_MUTEX_HAS_WAITERS ) ;
}
2022-12-02 13:02:23 +03:00
static __always_inline void
fixup_rt_mutex_waiters ( struct rt_mutex_base * lock , bool acquire_lock )
2006-06-27 13:54:53 +04:00
{
2016-12-01 00:04:41 +03:00
unsigned long owner , * p = ( unsigned long * ) & lock - > owner ;
if ( rt_mutex_has_waiters ( lock ) )
return ;
/*
* The rbtree has no waiters enqueued , now make sure that the
* lock - > owner still has the waiters bit set , otherwise the
* following can happen :
*
* CPU 0 CPU 1 CPU2
* l - > owner = T1
* rt_mutex_lock ( l )
* lock ( l - > lock )
* l - > owner = T1 | HAS_WAITERS ;
* enqueue ( T2 )
* boost ( )
* unlock ( l - > lock )
* block ( )
*
* rt_mutex_lock ( l )
* lock ( l - > lock )
* l - > owner = T1 | HAS_WAITERS ;
* enqueue ( T3 )
* boost ( )
* unlock ( l - > lock )
* block ( )
* signal ( - > T2 ) signal ( - > T3 )
* lock ( l - > lock )
* dequeue ( T2 )
* deboost ( )
* unlock ( l - > lock )
* lock ( l - > lock )
* dequeue ( T3 )
* = = > wait list is empty
* deboost ( )
* unlock ( l - > lock )
* lock ( l - > lock )
* fixup_rt_mutex_waiters ( )
* if ( wait_list_empty ( l ) {
* l - > owner = owner
* owner = l - > owner & ~ HAS_WAITERS ;
* = = > l - > owner = T1
* }
* lock ( l - > lock )
* rt_mutex_unlock ( l ) fixup_rt_mutex_waiters ( )
* if ( wait_list_empty ( l ) {
* owner = l - > owner & ~ HAS_WAITERS ;
* cmpxchg ( l - > owner , T1 , NULL )
* = = = > Success ( l - > owner = NULL )
*
* l - > owner = owner
* = = > l - > owner = T1
* }
*
* With the check for the waiter bit in place T3 on CPU2 will not
* overwrite . All tasks fiddling with the waiters bit are
* serialized by l - > lock , so nothing else can modify the waiters
* bit . If the bit is set then nothing can change l - > owner either
* so the simple RMW is safe . The cmpxchg ( ) will simply fail if it
* happens in the middle of the RMW because the waiters bit is
* still set .
*/
owner = READ_ONCE ( * p ) ;
2022-12-02 13:02:23 +03:00
if ( owner & RT_MUTEX_HAS_WAITERS ) {
/*
* See rt_mutex_set_owner ( ) and rt_mutex_clear_owner ( ) on
* why xchg_acquire ( ) is used for updating owner for
* locking and WRITE_ONCE ( ) for unlocking .
*
* WRITE_ONCE ( ) would work for the acquire case too , but
* in case that the lock acquisition failed it might
* force other lockers into the slow path unnecessarily .
*/
if ( acquire_lock )
xchg_acquire ( p , owner & ~ RT_MUTEX_HAS_WAITERS ) ;
else
WRITE_ONCE ( * p , owner & ~ RT_MUTEX_HAS_WAITERS ) ;
}
2006-06-27 13:54:53 +04:00
}
2007-06-17 23:11:10 +04:00
/*
2015-02-25 20:56:13 +03:00
* We can speed up the acquire / release , if there ' s no debugging state to be
* set up .
2007-06-17 23:11:10 +04:00
*/
2015-02-25 20:56:13 +03:00
# ifndef CONFIG_DEBUG_RT_MUTEXES
2021-08-16 00:27:58 +03:00
static __always_inline bool rt_mutex_cmpxchg_acquire ( struct rt_mutex_base * lock ,
2021-08-16 00:27:54 +03:00
struct task_struct * old ,
struct task_struct * new )
{
2021-08-16 00:27:55 +03:00
return try_cmpxchg_acquire ( & lock - > owner , & old , new ) ;
2021-08-16 00:27:54 +03:00
}
2023-09-08 19:22:49 +03:00
static __always_inline bool rt_mutex_try_acquire ( struct rt_mutex_base * lock )
{
return rt_mutex_cmpxchg_acquire ( lock , NULL , current ) ;
}
2021-08-16 00:27:58 +03:00
static __always_inline bool rt_mutex_cmpxchg_release ( struct rt_mutex_base * lock ,
2021-08-16 00:27:54 +03:00
struct task_struct * old ,
struct task_struct * new )
{
2021-08-16 00:27:55 +03:00
return try_cmpxchg_release ( & lock - > owner , & old , new ) ;
2021-08-16 00:27:54 +03:00
}
2015-09-30 23:03:13 +03:00
/*
* Callers must hold the - > wait_lock - - which is the whole purpose as we force
* all future threads that attempt to [ Rmw ] the lock to the slowpath . As such
* relaxed semantics suffice .
*/
2021-08-16 00:27:58 +03:00
static __always_inline void mark_rt_mutex_waiters ( struct rt_mutex_base * lock )
2007-06-17 23:11:10 +04:00
{
2024-01-24 13:49:53 +03:00
unsigned long * p = ( unsigned long * ) & lock - > owner ;
unsigned long owner , new ;
2007-06-17 23:11:10 +04:00
2024-01-24 13:49:53 +03:00
owner = READ_ONCE ( * p ) ;
2007-06-17 23:11:10 +04:00
do {
2024-01-24 13:49:53 +03:00
new = owner | RT_MUTEX_HAS_WAITERS ;
} while ( ! try_cmpxchg_relaxed ( p , & owner , new ) ) ;
2022-12-02 13:02:23 +03:00
/*
* The cmpxchg loop above is relaxed to avoid back - to - back ACQUIRE
* operations in the event of contention . Ensure the successful
* cmpxchg is visible .
*/
smp_mb__after_atomic ( ) ;
2007-06-17 23:11:10 +04:00
}
2014-06-11 22:44:04 +04:00
/*
* Safe fastpath aware unlock :
* 1 ) Clear the waiters bit
* 2 ) Drop lock - > wait_lock
* 3 ) Try to unlock the lock with cmpxchg
*/
2021-08-16 00:27:58 +03:00
static __always_inline bool unlock_rt_mutex_safe ( struct rt_mutex_base * lock ,
2021-03-26 18:29:40 +03:00
unsigned long flags )
2014-06-11 22:44:04 +04:00
__releases ( lock - > wait_lock )
{
struct task_struct * owner = rt_mutex_owner ( lock ) ;
clear_rt_mutex_waiters ( lock ) ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irqrestore ( & lock - > wait_lock , flags ) ;
2014-06-11 22:44:04 +04:00
/*
* If a new waiter comes in between the unlock and the cmpxchg
* we have two situations :
*
* unlock ( wait_lock ) ;
* lock ( wait_lock ) ;
* cmpxchg ( p , owner , 0 ) = = owner
* mark_rt_mutex_waiters ( lock ) ;
* acquire ( lock ) ;
* or :
*
* unlock ( wait_lock ) ;
* lock ( wait_lock ) ;
* mark_rt_mutex_waiters ( lock ) ;
*
* cmpxchg ( p , owner , 0 ) ! = owner
* enqueue_waiter ( ) ;
* unlock ( wait_lock ) ;
* lock ( wait_lock ) ;
* wake waiter ( ) ;
* unlock ( wait_lock ) ;
* lock ( wait_lock ) ;
* acquire ( lock ) ;
*/
2015-09-30 23:03:13 +03:00
return rt_mutex_cmpxchg_release ( lock , owner , NULL ) ;
2014-06-11 22:44:04 +04:00
}
2007-06-17 23:11:10 +04:00
# else
2021-08-16 00:27:58 +03:00
static __always_inline bool rt_mutex_cmpxchg_acquire ( struct rt_mutex_base * lock ,
2021-08-16 00:27:54 +03:00
struct task_struct * old ,
struct task_struct * new )
{
return false ;
}
2023-09-08 19:22:49 +03:00
static int __sched rt_mutex_slowtrylock ( struct rt_mutex_base * lock ) ;
static __always_inline bool rt_mutex_try_acquire ( struct rt_mutex_base * lock )
{
/*
* With debug enabled rt_mutex_cmpxchg trylock ( ) will always fail .
*
* Avoid unconditionally taking the slow path by using
* rt_mutex_slow_trylock ( ) which is covered by the debug code and can
* acquire a non - contended rtmutex .
*/
return rt_mutex_slowtrylock ( lock ) ;
}
2021-08-16 00:27:58 +03:00
static __always_inline bool rt_mutex_cmpxchg_release ( struct rt_mutex_base * lock ,
2021-08-16 00:27:54 +03:00
struct task_struct * old ,
struct task_struct * new )
{
return false ;
}
2015-09-30 23:03:13 +03:00
2021-08-16 00:27:58 +03:00
static __always_inline void mark_rt_mutex_waiters ( struct rt_mutex_base * lock )
2007-06-17 23:11:10 +04:00
{
lock - > owner = ( struct task_struct * )
( ( unsigned long ) lock - > owner | RT_MUTEX_HAS_WAITERS ) ;
}
2014-06-11 22:44:04 +04:00
/*
* Simple slow path only version : lock - > owner is protected by lock - > wait_lock .
*/
2021-08-16 00:27:58 +03:00
static __always_inline bool unlock_rt_mutex_safe ( struct rt_mutex_base * lock ,
2021-03-26 18:29:40 +03:00
unsigned long flags )
2014-06-11 22:44:04 +04:00
__releases ( lock - > wait_lock )
{
lock - > owner = NULL ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irqrestore ( & lock - > wait_lock , flags ) ;
2014-06-11 22:44:04 +04:00
return true ;
}
2007-06-17 23:11:10 +04:00
# endif
2021-08-16 00:28:30 +03:00
static __always_inline int __waiter_prio ( struct task_struct * task )
{
int prio = task - > prio ;
if ( ! rt_prio ( prio ) )
return DEFAULT_PRIO ;
return prio ;
}
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
/*
* Update the waiter - > tree copy of the sort keys .
*/
2021-08-16 00:28:30 +03:00
static __always_inline void
waiter_update_prio ( struct rt_mutex_waiter * waiter , struct task_struct * task )
{
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
lockdep_assert_held ( & waiter - > lock - > wait_lock ) ;
lockdep_assert ( RB_EMPTY_NODE ( & waiter - > tree . entry ) ) ;
waiter - > tree . prio = __waiter_prio ( task ) ;
waiter - > tree . deadline = task - > dl . deadline ;
}
/*
* Update the waiter - > pi_tree copy of the sort keys ( from the tree copy ) .
*/
static __always_inline void
waiter_clone_prio ( struct rt_mutex_waiter * waiter , struct task_struct * task )
{
lockdep_assert_held ( & waiter - > lock - > wait_lock ) ;
lockdep_assert_held ( & task - > pi_lock ) ;
lockdep_assert ( RB_EMPTY_NODE ( & waiter - > pi_tree . entry ) ) ;
waiter - > pi_tree . prio = waiter - > tree . prio ;
waiter - > pi_tree . deadline = waiter - > tree . deadline ;
2021-08-16 00:28:30 +03:00
}
2017-03-23 17:56:14 +03:00
/*
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
* Only use with rt_waiter_node_ { less , equal } ( )
2017-03-23 17:56:14 +03:00
*/
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
# define task_to_waiter_node(p) \
& ( struct rt_waiter_node ) { . prio = __waiter_prio ( p ) , . deadline = ( p ) - > dl . deadline }
2017-03-23 17:56:14 +03:00
# define task_to_waiter(p) \
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
& ( struct rt_mutex_waiter ) { . tree = * task_to_waiter_node ( p ) }
2017-03-23 17:56:14 +03:00
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
static __always_inline int rt_waiter_node_less ( struct rt_waiter_node * left ,
struct rt_waiter_node * right )
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
{
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:44 +04:00
if ( left - > prio < right - > prio )
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
return 1 ;
/*
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:44 +04:00
* If both waiters have dl_prio ( ) , we check the deadlines of the
* associated tasks .
* If left waiter has a dl_prio ( ) , and we didn ' t return 1 above ,
* then right waiter has a dl_prio ( ) too .
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
*/
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:44 +04:00
if ( dl_prio ( left - > prio ) )
2017-03-23 17:56:13 +03:00
return dl_time_before ( left - > deadline , right - > deadline ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
return 0 ;
}
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
static __always_inline int rt_waiter_node_equal ( struct rt_waiter_node * left ,
struct rt_waiter_node * right )
2017-03-23 17:56:14 +03:00
{
if ( left - > prio ! = right - > prio )
return 0 ;
/*
* If both waiters have dl_prio ( ) , we check the deadlines of the
* associated tasks .
* If left waiter has a dl_prio ( ) , and we didn ' t return 0 above ,
* then right waiter has a dl_prio ( ) too .
*/
if ( dl_prio ( left - > prio ) )
return left - > deadline = = right - > deadline ;
return 1 ;
}
2021-08-16 00:29:23 +03:00
static inline bool rt_mutex_steal ( struct rt_mutex_waiter * waiter ,
struct rt_mutex_waiter * top_waiter )
{
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
if ( rt_waiter_node_less ( & waiter - > tree , & top_waiter - > tree ) )
2021-08-16 00:29:23 +03:00
return true ;
# ifdef RT_MUTEX_BUILD_SPINLOCKS
/*
* Note that RT tasks are excluded from same priority ( lateral )
* steals to prevent the introduction of an unbounded latency .
*/
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
if ( rt_prio ( waiter - > tree . prio ) | | dl_prio ( waiter - > tree . prio ) )
2021-08-16 00:29:23 +03:00
return false ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
return rt_waiter_node_equal ( & waiter - > tree , & top_waiter - > tree ) ;
2021-08-16 00:29:23 +03:00
# else
return false ;
# endif
}
2020-04-29 18:29:58 +03:00
# define __node_2_waiter(node) \
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rb_entry ( ( node ) , struct rt_mutex_waiter , tree . entry )
2020-04-29 18:29:58 +03:00
2021-03-26 18:29:40 +03:00
static __always_inline bool __waiter_less ( struct rb_node * a , const struct rb_node * b )
2020-04-29 18:29:58 +03:00
{
2021-08-16 00:28:58 +03:00
struct rt_mutex_waiter * aw = __node_2_waiter ( a ) ;
struct rt_mutex_waiter * bw = __node_2_waiter ( b ) ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
if ( rt_waiter_node_less ( & aw - > tree , & bw - > tree ) )
2021-08-16 00:28:58 +03:00
return 1 ;
if ( ! build_ww_mutex ( ) )
return 0 ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
if ( rt_waiter_node_less ( & bw - > tree , & aw - > tree ) )
2021-08-16 00:28:58 +03:00
return 0 ;
/* NOTE: relies on waiter->ww_ctx being set before insertion */
if ( aw - > ww_ctx ) {
if ( ! bw - > ww_ctx )
return 1 ;
return ( signed long ) ( aw - > ww_ctx - > stamp -
bw - > ww_ctx - > stamp ) < 0 ;
}
return 0 ;
2020-04-29 18:29:58 +03:00
}
2021-03-26 18:29:40 +03:00
static __always_inline void
2021-08-16 00:27:58 +03:00
rt_mutex_enqueue ( struct rt_mutex_base * lock , struct rt_mutex_waiter * waiter )
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
{
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
rb_add_cached ( & waiter - > tree . entry , & lock - > waiters , __waiter_less ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
}
2021-03-26 18:29:40 +03:00
static __always_inline void
2021-08-16 00:27:58 +03:00
rt_mutex_dequeue ( struct rt_mutex_base * lock , struct rt_mutex_waiter * waiter )
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
{
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
if ( RB_EMPTY_NODE ( & waiter - > tree . entry ) )
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
return ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rb_erase_cached ( & waiter - > tree . entry , & lock - > waiters ) ;
RB_CLEAR_NODE ( & waiter - > tree . entry ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
}
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
# define __node_2_rt_node(node) \
rb_entry ( ( node ) , struct rt_waiter_node , entry )
2020-04-29 18:29:58 +03:00
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
static __always_inline bool __pi_waiter_less ( struct rb_node * a , const struct rb_node * b )
2020-04-29 18:29:58 +03:00
{
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
return rt_waiter_node_less ( __node_2_rt_node ( a ) , __node_2_rt_node ( b ) ) ;
2020-04-29 18:29:58 +03:00
}
2021-03-26 18:29:40 +03:00
static __always_inline void
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_enqueue_pi ( struct task_struct * task , struct rt_mutex_waiter * waiter )
{
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
lockdep_assert_held ( & task - > pi_lock ) ;
rb_add_cached ( & waiter - > pi_tree . entry , & task - > pi_waiters , __pi_waiter_less ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
}
2021-03-26 18:29:40 +03:00
static __always_inline void
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_dequeue_pi ( struct task_struct * task , struct rt_mutex_waiter * waiter )
{
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
lockdep_assert_held ( & task - > pi_lock ) ;
if ( RB_EMPTY_NODE ( & waiter - > pi_tree . entry ) )
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
return ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rb_erase_cached ( & waiter - > pi_tree . entry , & task - > pi_waiters ) ;
RB_CLEAR_NODE ( & waiter - > pi_tree . entry ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
}
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
static __always_inline void rt_mutex_adjust_prio ( struct rt_mutex_base * lock ,
struct task_struct * p )
2014-02-07 23:58:42 +04:00
{
2017-03-23 17:56:11 +03:00
struct task_struct * pi_task = NULL ;
2017-03-23 17:56:08 +03:00
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
lockdep_assert ( rt_mutex_owner ( lock ) = = p ) ;
2017-03-23 17:56:11 +03:00
lockdep_assert_held ( & p - > pi_lock ) ;
2014-02-07 23:58:42 +04:00
2017-03-23 17:56:11 +03:00
if ( task_has_pi_waiters ( p ) )
pi_task = task_top_pi_waiter ( p ) - > task ;
2014-02-07 23:58:42 +04:00
2017-03-23 17:56:11 +03:00
rt_mutex_setprio ( p , pi_task ) ;
2006-06-27 13:54:53 +04:00
}
2021-08-16 00:28:08 +03:00
/* RT mutex specific wake_q wrappers */
2021-09-28 18:00:06 +03:00
static __always_inline void rt_mutex_wake_q_add_task ( struct rt_wake_q_head * wqh ,
struct task_struct * task ,
unsigned int wake_state )
2021-08-16 00:28:08 +03:00
{
2021-09-28 18:00:06 +03:00
if ( IS_ENABLED ( CONFIG_PREEMPT_RT ) & & wake_state = = TASK_RTLOCK_WAIT ) {
2021-08-16 00:28:11 +03:00
if ( IS_ENABLED ( CONFIG_PROVE_LOCKING ) )
WARN_ON_ONCE ( wqh - > rtlock_task ) ;
2021-09-28 18:00:06 +03:00
get_task_struct ( task ) ;
wqh - > rtlock_task = task ;
2021-08-16 00:28:11 +03:00
} else {
2021-09-28 18:00:06 +03:00
wake_q_add ( & wqh - > head , task ) ;
2021-08-16 00:28:11 +03:00
}
2021-08-16 00:28:08 +03:00
}
2021-09-28 18:00:06 +03:00
static __always_inline void rt_mutex_wake_q_add ( struct rt_wake_q_head * wqh ,
struct rt_mutex_waiter * w )
{
rt_mutex_wake_q_add_task ( wqh , w - > task , w - > wake_state ) ;
}
2021-08-16 00:28:08 +03:00
static __always_inline void rt_mutex_wake_up_q ( struct rt_wake_q_head * wqh )
{
2021-08-16 00:28:11 +03:00
if ( IS_ENABLED ( CONFIG_PREEMPT_RT ) & & wqh - > rtlock_task ) {
wake_up_state ( wqh - > rtlock_task , TASK_RTLOCK_WAIT ) ;
put_task_struct ( wqh - > rtlock_task ) ;
wqh - > rtlock_task = NULL ;
}
if ( ! wake_q_empty ( & wqh - > head ) )
wake_up_q ( & wqh - > head ) ;
2021-08-16 00:28:08 +03:00
/* Pairs with preempt_disable() in mark_wakeup_next_waiter() */
preempt_enable ( ) ;
}
2014-05-22 07:25:47 +04:00
/*
* Deadlock detection is conditional :
*
* If CONFIG_DEBUG_RT_MUTEXES = n , deadlock detection is only conducted
* if the detect argument is = = RT_MUTEX_FULL_CHAINWALK .
*
* If CONFIG_DEBUG_RT_MUTEXES = y , deadlock detection is always
* conducted independent of the detect argument .
*
* If the waiter argument is NULL this indicates the deboost path and
* deadlock detection is disabled independent of the detect argument
* and the config settings .
*/
2021-03-26 18:29:40 +03:00
static __always_inline bool
rt_mutex_cond_detect_deadlock ( struct rt_mutex_waiter * waiter ,
enum rtmutex_chainwalk chwalk )
2014-05-22 07:25:47 +04:00
{
2021-07-31 15:30:11 +03:00
if ( IS_ENABLED ( CONFIG_DEBUG_RT_MUTEXES ) )
2021-03-26 18:29:36 +03:00
return waiter ! = NULL ;
return chwalk = = RT_MUTEX_FULL_CHAINWALK ;
2014-05-22 07:25:47 +04:00
}
2021-08-16 00:27:58 +03:00
static __always_inline struct rt_mutex_base * task_blocked_on_lock ( struct task_struct * p )
2014-06-05 13:16:12 +04:00
{
return p - > pi_blocked_on ? p - > pi_blocked_on - > lock : NULL ;
}
2006-06-27 13:54:53 +04:00
/*
* Adjust the priority chain . Also used for deadlock detection .
* Decreases task ' s usage by one - may thus free the task .
2013-05-15 13:04:10 +04:00
*
2014-06-05 13:16:12 +04:00
* @ task : the task owning the mutex ( owner ) for which a chain walk is
* probably needed
2015-03-18 08:03:30 +03:00
* @ chwalk : do we have to carry out deadlock detection ?
2014-06-05 13:16:12 +04:00
* @ orig_lock : the mutex ( can be NULL if we are walking the chain to recheck
* things for a task that has just got its priority adjusted , and
* is waiting on a mutex )
* @ next_lock : the mutex on which the owner of @ orig_lock was blocked before
* we dropped its pi_lock . Is never dereferenced , only used for
* comparison to detect lock chain changes .
2013-05-15 13:04:10 +04:00
* @ orig_waiter : rt_mutex_waiter struct for the task that has just donated
2014-06-05 13:16:12 +04:00
* its priority to the mutex owner ( can be NULL in the case
* depicted above or if the top waiter is gone away and we are
* actually deboosting the owner )
* @ top_task : the current top waiter
2013-05-15 13:04:10 +04:00
*
2006-06-27 13:54:53 +04:00
* Returns 0 or - EDEADLK .
2014-06-09 21:40:34 +04:00
*
* Chain walk basics and protection scope
*
* [ R ] refcount on task
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
* [ Pn ] task - > pi_lock held
2014-06-09 21:40:34 +04:00
* [ L ] rtmutex - > wait_lock held
*
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
* Normal locking order :
*
* rtmutex - > wait_lock
* task - > pi_lock
*
2014-06-09 21:40:34 +04:00
* Step Description Protected by
* function arguments :
* @ task [ R ]
* @ orig_lock if ! = NULL @ top_task is blocked on it
* @ next_lock Unprotected . Cannot be
* dereferenced . Only used for
* comparison .
* @ orig_waiter if ! = NULL @ top_task is blocked on it
* @ top_task current , or in case of proxy
* locking protected by calling
* code
* again :
* loop_sanity_check ( ) ;
* retry :
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
* [ 1 ] lock ( task - > pi_lock ) ; [ R ] acquire [ P1 ]
* [ 2 ] waiter = task - > pi_blocked_on ; [ P1 ]
* [ 3 ] check_exit_conditions_1 ( ) ; [ P1 ]
* [ 4 ] lock = waiter - > lock ; [ P1 ]
* [ 5 ] if ( ! try_lock ( lock - > wait_lock ) ) { [ P1 ] try to acquire [ L ]
* unlock ( task - > pi_lock ) ; release [ P1 ]
2014-06-09 21:40:34 +04:00
* goto retry ;
* }
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
* [ 6 ] check_exit_conditions_2 ( ) ; [ P1 ] + [ L ]
* [ 7 ] requeue_lock_waiter ( lock , waiter ) ; [ P1 ] + [ L ]
* [ 8 ] unlock ( task - > pi_lock ) ; release [ P1 ]
2014-06-09 21:40:34 +04:00
* put_task_struct ( task ) ; release [ R ]
* [ 9 ] check_exit_conditions_3 ( ) ; [ L ]
* [ 10 ] task = owner ( lock ) ; [ L ]
* get_task_struct ( task ) ; [ L ] acquire [ R ]
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
* lock ( task - > pi_lock ) ; [ L ] acquire [ P2 ]
* [ 11 ] requeue_pi_waiter ( tsk , waiters ( lock ) ) ; [ P2 ] + [ L ]
* [ 12 ] check_exit_conditions_4 ( ) ; [ P2 ] + [ L ]
* [ 13 ] unlock ( task - > pi_lock ) ; release [ P2 ]
2014-06-09 21:40:34 +04:00
* unlock ( lock - > wait_lock ) ; release [ L ]
* goto again ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
*
* Where P1 is the blocking task and P2 is the lock owner ; going up one step
* the owner becomes the next blocked task etc . .
*
*
2006-06-27 13:54:53 +04:00
*/
2021-03-26 18:29:40 +03:00
static int __sched rt_mutex_adjust_prio_chain ( struct task_struct * task ,
enum rtmutex_chainwalk chwalk ,
2021-08-16 00:27:58 +03:00
struct rt_mutex_base * orig_lock ,
struct rt_mutex_base * next_lock ,
2021-03-26 18:29:40 +03:00
struct rt_mutex_waiter * orig_waiter ,
struct task_struct * top_task )
2006-06-27 13:54:53 +04:00
{
struct rt_mutex_waiter * waiter , * top_waiter = orig_waiter ;
2014-05-22 07:25:54 +04:00
struct rt_mutex_waiter * prerequeue_top_waiter ;
2014-05-22 07:25:47 +04:00
int ret = 0 , depth = 0 ;
2021-08-16 00:27:58 +03:00
struct rt_mutex_base * lock ;
2014-05-22 07:25:47 +04:00
bool detect_deadlock ;
2014-05-22 07:25:57 +04:00
bool requeue = true ;
2006-06-27 13:54:53 +04:00
2014-05-22 07:25:47 +04:00
detect_deadlock = rt_mutex_cond_detect_deadlock ( orig_waiter , chwalk ) ;
2006-06-27 13:54:53 +04:00
/*
* The ( de ) boosting is a step by step approach with a lot of
* pitfalls . We want this to be preemptible and we want hold a
* maximum of two locks per step . So we have to check
* carefully whether things change under us .
*/
again :
2014-06-09 21:40:34 +04:00
/*
* We limit the lock chain length for each invocation .
*/
2006-06-27 13:54:53 +04:00
if ( + + depth > max_lock_depth ) {
static int prev_max ;
/*
* Print this only once . If the admin changes the limit ,
* print a new message when reaching the limit again .
*/
if ( prev_max ! = max_lock_depth ) {
prev_max = max_lock_depth ;
printk ( KERN_WARNING " Maximum lock depth %d reached "
" task: %s (%d) \n " , max_lock_depth ,
2007-10-19 10:40:40 +04:00
top_task - > comm , task_pid_nr ( top_task ) ) ;
2006-06-27 13:54:53 +04:00
}
put_task_struct ( task ) ;
2014-06-05 14:34:23 +04:00
return - EDEADLK ;
2006-06-27 13:54:53 +04:00
}
2014-06-09 21:40:34 +04:00
/*
* We are fully preemptible here and only hold the refcount on
* @ task . So everything can have changed under us since the
* caller or our own code below ( goto retry / again ) dropped all
* locks .
*/
2006-06-27 13:54:53 +04:00
retry :
/*
2014-06-09 21:40:34 +04:00
* [ 1 ] Task cannot go away as we did a get_task ( ) before !
2006-06-27 13:54:53 +04:00
*/
2016-01-13 13:25:38 +03:00
raw_spin_lock_irq ( & task - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
2014-06-09 21:40:34 +04:00
/*
* [ 2 ] Get the waiter on which @ task is blocked on .
*/
2006-06-27 13:54:53 +04:00
waiter = task - > pi_blocked_on ;
2014-06-09 21:40:34 +04:00
/*
* [ 3 ] check_exit_conditions_1 ( ) protected by task - > pi_lock .
*/
2006-06-27 13:54:53 +04:00
/*
* Check whether the end of the boosting chain has been
* reached or the state of the chain has changed while we
* dropped the locks .
*/
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
if ( ! waiter )
2006-06-27 13:54:53 +04:00
goto out_unlock_pi ;
2007-06-09 00:46:58 +04:00
/*
* Check the orig_waiter state . After we dropped the locks ,
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
* the previous owner of the lock might have released the lock .
2007-06-09 00:46:58 +04:00
*/
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
if ( orig_waiter & & ! rt_mutex_owner ( orig_lock ) )
2007-06-09 00:46:58 +04:00
goto out_unlock_pi ;
2014-06-05 13:16:12 +04:00
/*
* We dropped all locks after taking a refcount on @ task , so
* the task might have moved on in the lock chain or even left
* the chain completely and blocks now on an unrelated lock or
* on @ orig_lock .
*
* We stored the lock on which @ task was blocked in @ next_lock ,
* so we can detect the chain change .
*/
if ( next_lock ! = waiter - > lock )
goto out_unlock_pi ;
2021-08-26 10:36:53 +03:00
/*
* There could be ' spurious ' loops in the lock graph due to ww_mutex ,
* consider :
*
* P1 : A , ww_A , ww_B
* P2 : ww_B , ww_A
* P3 : A
*
* P3 should not return - EDEADLK because it gets trapped in the cycle
* created by P1 and P2 ( which will resolve - - and runs into
* max_lock_depth above ) . Therefore disable detect_deadlock such that
* the below termination condition can trigger once all relevant tasks
* are boosted .
*
* Even when we start with ww_mutex we can disable deadlock detection ,
* since we would supress a ww_mutex induced deadlock at [ 6 ] anyway .
* Supressing it here however is not sufficient since we might still
* hit [ 6 ] due to adjustment driven iteration .
*
* NOTE : if someone were to create a deadlock between 2 ww_classes we ' d
* utterly fail to report it ; lockdep should .
*/
if ( IS_ENABLED ( CONFIG_PREEMPT_RT ) & & waiter - > ww_ctx & & detect_deadlock )
detect_deadlock = false ;
2007-06-09 00:46:58 +04:00
/*
* Drop out , when the task has no waiters . Note ,
* top_waiter can be NULL , when we are in the deboosting
* mode !
*/
2014-05-22 07:25:39 +04:00
if ( top_waiter ) {
if ( ! task_has_pi_waiters ( task ) )
goto out_unlock_pi ;
/*
* If deadlock detection is off , we stop here if we
2014-05-22 07:25:57 +04:00
* are not the top pi waiter of the task . If deadlock
* detection is enabled we continue , but stop the
* requeueing in the chain walk .
2014-05-22 07:25:39 +04:00
*/
2014-05-22 07:25:57 +04:00
if ( top_waiter ! = task_top_pi_waiter ( task ) ) {
if ( ! detect_deadlock )
goto out_unlock_pi ;
else
requeue = false ;
}
2014-05-22 07:25:39 +04:00
}
2006-06-27 13:54:53 +04:00
/*
2014-05-22 07:25:57 +04:00
* If the waiter priority is the same as the task priority
* then there is no further priority adjustment necessary . If
* deadlock detection is off , we stop the chain walk . If its
* enabled we continue , but stop the requeueing in the chain
* walk .
2006-06-27 13:54:53 +04:00
*/
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
if ( rt_waiter_node_equal ( & waiter - > tree , task_to_waiter_node ( task ) ) ) {
2014-05-22 07:25:57 +04:00
if ( ! detect_deadlock )
goto out_unlock_pi ;
else
requeue = false ;
}
2006-06-27 13:54:53 +04:00
2014-06-09 21:40:34 +04:00
/*
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
* [ 4 ] Get the next lock ; per holding task - > pi_lock we can ' t unblock
* and guarantee @ lock ' s existence .
2014-06-09 21:40:34 +04:00
*/
2006-06-27 13:54:53 +04:00
lock = waiter - > lock ;
2014-06-09 21:40:34 +04:00
/*
* [ 5 ] We need to trylock here as we are holding task - > pi_lock ,
* which is the reverse lock order versus the other rtmutex
* operations .
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
*
* Per the above , holding task - > pi_lock guarantees lock exists , so
* inverting this lock order is infeasible from a life - time
* perspective .
2014-06-09 21:40:34 +04:00
*/
2009-11-17 20:22:11 +03:00
if ( ! raw_spin_trylock ( & lock - > wait_lock ) ) {
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irq ( & task - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
cpu_relax ( ) ;
goto retry ;
}
2014-05-22 07:25:39 +04:00
/*
2014-06-09 21:40:34 +04:00
* [ 6 ] check_exit_conditions_2 ( ) protected by task - > pi_lock and
* lock - > wait_lock .
*
2014-05-22 07:25:39 +04:00
* Deadlock detection . If the lock is the same as the original
* lock which caused us to walk the lock chain or if the
* current lock is owned by the task which initiated the chain
* walk , we detected a deadlock .
*/
2006-06-27 13:55:02 +04:00
if ( lock = = orig_lock | | rt_mutex_owner ( lock ) = = top_task ) {
2014-06-05 14:34:23 +04:00
ret = - EDEADLK ;
2021-08-26 11:48:18 +03:00
/*
* When the deadlock is due to ww_mutex ; also see above . Don ' t
* report the deadlock and instead let the ww_mutex wound / die
* logic pick which of the contending threads gets - EDEADLK .
*
* NOTE : assumes the cycle only contains a single ww_class ; any
* other configuration and we fail to report ; also , see
* lockdep .
*/
2021-09-01 12:44:11 +03:00
if ( IS_ENABLED ( CONFIG_PREEMPT_RT ) & & orig_waiter & & orig_waiter - > ww_ctx )
2021-08-26 11:48:18 +03:00
ret = 0 ;
raw_spin_unlock ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
goto out_unlock_pi ;
}
2014-05-22 07:25:57 +04:00
/*
* If we just follow the lock chain for deadlock detection , no
* need to do all the requeue operations . To avoid a truckload
* of conditionals around the various places below , just do the
* minimum chain walk checks .
*/
if ( ! requeue ) {
/*
* No requeue [ 7 ] here . Just release @ task [ 8 ]
*/
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & task - > pi_lock ) ;
2014-05-22 07:25:57 +04:00
put_task_struct ( task ) ;
/*
* [ 9 ] check_exit_conditions_3 protected by lock - > wait_lock .
* If there is no owner of the lock , end of chain .
*/
if ( ! rt_mutex_owner ( lock ) ) {
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2014-05-22 07:25:57 +04:00
return 0 ;
}
/* [10] Grab the next task, i.e. owner of @lock */
2019-07-05 01:13:23 +03:00
task = get_task_struct ( rt_mutex_owner ( lock ) ) ;
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & task - > pi_lock ) ;
2014-05-22 07:25:57 +04:00
/*
* No requeue [ 11 ] here . We just do deadlock detection .
*
* [ 12 ] Store whether owner is blocked
* itself . Decision is made after dropping the locks
*/
next_lock = task_blocked_on_lock ( task ) ;
/*
* Get the top waiter for the next iteration
*/
top_waiter = rt_mutex_top_waiter ( lock ) ;
/* [13] Drop locks */
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & task - > pi_lock ) ;
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2014-05-22 07:25:57 +04:00
/* If owner is not blocked, end of chain. */
if ( ! next_lock )
goto out_put_task ;
goto again ;
}
2014-05-22 07:25:54 +04:00
/*
* Store the current top waiter before doing the requeue
* operation on @ lock . We need it for the boost / deboost
* decision below .
*/
prerequeue_top_waiter = rt_mutex_top_waiter ( lock ) ;
2006-06-27 13:54:53 +04:00
2015-05-19 20:24:57 +03:00
/* [7] Requeue the waiter in the lock waiter tree. */
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_dequeue ( lock , waiter ) ;
2017-03-23 17:56:13 +03:00
/*
* Update the waiter prio fields now that we ' re dequeued .
*
* These values can have changed through either :
*
* sys_sched_set_scheduler ( ) / sys_sched_setattr ( )
*
* or
*
* DL CBS enforcement advancing the effective deadline .
*/
2021-08-16 00:28:30 +03:00
waiter_update_prio ( waiter , task ) ;
2017-03-23 17:56:13 +03:00
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_enqueue ( lock , waiter ) ;
2006-06-27 13:54:53 +04:00
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
/*
* [ 8 ] Release the ( blocking ) task in preparation for
* taking the owner task in [ 10 ] .
*
* Since we hold lock - > waiter_lock , task cannot unblock , even if we
* release task - > pi_lock .
*/
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & task - > pi_lock ) ;
2014-06-07 14:10:36 +04:00
put_task_struct ( task ) ;
2014-05-22 07:25:54 +04:00
/*
2014-06-09 21:40:34 +04:00
* [ 9 ] check_exit_conditions_3 protected by lock - > wait_lock .
*
2014-05-22 07:25:54 +04:00
* We must abort the chain walk if there is no lock owner even
* in the dead lock detection case , as we have nothing to
* follow here . This is the end of the chain we are walking .
*/
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
if ( ! rt_mutex_owner ( lock ) ) {
/*
2014-06-09 21:40:34 +04:00
* If the requeue [ 7 ] above changed the top waiter ,
* then we need to wake the new top waiter up to try
* to get the lock .
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
*/
rtmutex: Ensure that the top waiter is always woken up
Let L1 and L2 be two spinlocks.
Let T1 be a task holding L1 and blocked on L2. T1, currently, is the top
waiter of L2.
Let T2 be the task holding L2.
Let T3 be a task trying to acquire L1.
The following events will lead to a state in which the wait queue of L2
isn't empty, but no task actually holds the lock.
T1 T2 T3
== == ==
spin_lock(L1)
| raw_spin_lock(L1->wait_lock)
| rtlock_slowlock_locked(L1)
| | task_blocks_on_rt_mutex(L1, T3)
| | | orig_waiter->lock = L1
| | | orig_waiter->task = T3
| | | raw_spin_unlock(L1->wait_lock)
| | | rt_mutex_adjust_prio_chain(T1, L1, L2, orig_waiter, T3)
spin_unlock(L2) | | | |
| rt_mutex_slowunlock(L2) | | | |
| | raw_spin_lock(L2->wait_lock) | | | |
| | wakeup(T1) | | | |
| | raw_spin_unlock(L2->wait_lock) | | | |
| | | | waiter = T1->pi_blocked_on
| | | | waiter == rt_mutex_top_waiter(L2)
| | | | waiter->task == T1
| | | | raw_spin_lock(L2->wait_lock)
| | | | dequeue(L2, waiter)
| | | | update_prio(waiter, T1)
| | | | enqueue(L2, waiter)
| | | | waiter != rt_mutex_top_waiter(L2)
| | | | L2->owner == NULL
| | | | wakeup(T1)
| | | | raw_spin_unlock(L2->wait_lock)
T1 wakes up
T1 != top_waiter(L2)
schedule_rtlock()
If the deadline of T1 is updated before the call to update_prio(), and the
new deadline is greater than the deadline of the second top waiter, then
after the requeue, T1 is no longer the top waiter, and the wrong task is
woken up which will then go back to sleep because it is not the top waiter.
This can be reproduced in PREEMPT_RT with stress-ng:
while true; do
stress-ng --sched deadline --sched-period 1000000000 \
--sched-runtime 800000000 --sched-deadline \
1000000000 --mmapfork 23 -t 20
done
A similar issue was pointed out by Thomas versus the cases where the top
waiter drops out early due to a signal or timeout, which is a general issue
for all regular rtmutex use cases, e.g. futex.
The problematic code is in rt_mutex_adjust_prio_chain():
// Save the top waiter before dequeue/enqueue
prerequeue_top_waiter = rt_mutex_top_waiter(lock);
rt_mutex_dequeue(lock, waiter);
waiter_update_prio(waiter, task);
rt_mutex_enqueue(lock, waiter);
// Lock has no owner?
if (!rt_mutex_owner(lock)) {
// Top waiter changed
----> if (prerequeue_top_waiter != rt_mutex_top_waiter(lock))
----> wake_up_state(waiter->task, waiter->wake_state);
This only takes the case into account where @waiter is the new top waiter
due to the requeue operation.
But it fails to handle the case where @waiter is not longer the top
waiter due to the requeue operation.
Ensure that the new top waiter is woken up so in all cases so it can take
over the ownerless lock.
[ tglx: Amend changelog, add Fixes tag ]
Fixes: c014ef69b3ac ("locking/rtmutex: Add wake_state to rt_mutex_waiter")
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230117172649.52465-1-wander@redhat.com
Link: https://lore.kernel.org/r/20230202123020.14844-1-wander@redhat.com
2023-02-02 15:30:20 +03:00
top_waiter = rt_mutex_top_waiter ( lock ) ;
if ( prerequeue_top_waiter ! = top_waiter )
wake_up_state ( top_waiter - > task , top_waiter - > wake_state ) ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2014-06-07 14:10:36 +04:00
return 0 ;
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
}
2006-06-27 13:54:53 +04:00
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
/*
* [ 10 ] Grab the next task , i . e . the owner of @ lock
*
* Per holding lock - > wait_lock and checking for ! owner above , there
* must be an owner and it cannot go away .
*/
2019-07-05 01:13:23 +03:00
task = get_task_struct ( rt_mutex_owner ( lock ) ) ;
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & task - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
2014-06-09 21:40:34 +04:00
/* [11] requeue the pi waiters if necessary */
2006-06-27 13:54:53 +04:00
if ( waiter = = rt_mutex_top_waiter ( lock ) ) {
2014-05-22 07:25:54 +04:00
/*
* The waiter became the new top ( highest priority )
* waiter on the lock . Replace the previous top waiter
2015-05-19 20:24:57 +03:00
* in the owner tasks pi waiters tree with this waiter
2014-05-22 07:25:54 +04:00
* and adjust the priority of the owner .
*/
rt_mutex_dequeue_pi ( task , prerequeue_top_waiter ) ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
waiter_clone_prio ( waiter , task ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_enqueue_pi ( task , waiter ) ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rt_mutex_adjust_prio ( lock , task ) ;
2006-06-27 13:54:53 +04:00
2014-05-22 07:25:54 +04:00
} else if ( prerequeue_top_waiter = = waiter ) {
/*
* The waiter was the top waiter on the lock , but is
2021-03-22 04:35:05 +03:00
* no longer the top priority waiter . Replace waiter in
2015-05-19 20:24:57 +03:00
* the owner tasks pi waiters tree with the new top
2014-05-22 07:25:54 +04:00
* ( highest priority ) waiter and adjust the priority
* of the owner .
* The new top waiter is stored in @ waiter so that
* @ waiter = = @ top_waiter evaluates to true below and
* we continue to deboost the rest of the chain .
*/
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_dequeue_pi ( task , waiter ) ;
2006-06-27 13:54:53 +04:00
waiter = rt_mutex_top_waiter ( lock ) ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
waiter_clone_prio ( waiter , task ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_enqueue_pi ( task , waiter ) ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rt_mutex_adjust_prio ( lock , task ) ;
2014-05-22 07:25:54 +04:00
} else {
/*
* Nothing changed . No need to do any priority
* adjustment .
*/
2006-06-27 13:54:53 +04:00
}
2014-06-05 13:16:12 +04:00
/*
2014-06-09 21:40:34 +04:00
* [ 12 ] check_exit_conditions_4 ( ) protected by task - > pi_lock
* and lock - > wait_lock . The actual decisions are made after we
* dropped the locks .
*
2014-06-05 13:16:12 +04:00
* Check whether the task which owns the current lock is pi
* blocked itself . If yes we store a pointer to the lock for
* the lock chain change detection above . After we dropped
* task - > pi_lock next_lock cannot be dereferenced anymore .
*/
next_lock = task_blocked_on_lock ( task ) ;
2014-05-22 07:25:54 +04:00
/*
* Store the top waiter of @ lock for the end of chain walk
* decision below .
*/
2006-06-27 13:54:53 +04:00
top_waiter = rt_mutex_top_waiter ( lock ) ;
2014-06-09 21:40:34 +04:00
/* [13] Drop the locks */
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & task - > pi_lock ) ;
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
2014-06-05 13:16:12 +04:00
/*
2014-06-09 21:40:34 +04:00
* Make the actual exit decisions [ 12 ] , based on the stored
* values .
*
2014-06-05 13:16:12 +04:00
* We reached the end of the lock chain . Stop right here . No
* point to go back just to figure that out .
*/
if ( ! next_lock )
goto out_put_task ;
2014-05-22 07:25:54 +04:00
/*
* If the current waiter is not the top waiter on the lock ,
* then we can stop the chain walk here if we are not in full
* deadlock detection mode .
*/
2006-06-27 13:54:53 +04:00
if ( ! detect_deadlock & & waiter ! = top_waiter )
goto out_put_task ;
goto again ;
out_unlock_pi :
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irq ( & task - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
out_put_task :
put_task_struct ( task ) ;
2006-07-03 11:25:41 +04:00
2006-06-27 13:54:53 +04:00
return ret ;
}
/*
* Try to take an rt - mutex
*
2016-01-13 13:25:38 +03:00
* Must be called with lock - > wait_lock held and interrupts disabled
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
*
2014-06-11 03:01:13 +04:00
* @ lock : The lock to be acquired .
* @ task : The task which wants to acquire the lock
2015-05-19 20:24:57 +03:00
* @ waiter : The waiter that is queued to the lock ' s wait tree if the
2014-06-11 03:01:13 +04:00
* callsite called task_blocked_on_lock ( ) , otherwise NULL
2006-06-27 13:54:53 +04:00
*/
2021-03-26 18:29:40 +03:00
static int __sched
2021-08-16 00:27:58 +03:00
try_to_take_rt_mutex ( struct rt_mutex_base * lock , struct task_struct * task ,
2021-03-26 18:29:40 +03:00
struct rt_mutex_waiter * waiter )
2006-06-27 13:54:53 +04:00
{
2017-03-23 17:56:13 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
/*
2014-06-11 03:01:13 +04:00
* Before testing whether we can acquire @ lock , we set the
* RT_MUTEX_HAS_WAITERS bit in @ lock - > owner . This forces all
* other tasks which try to modify @ lock into the slow path
* and they serialize on @ lock - > wait_lock .
2006-06-27 13:54:53 +04:00
*
2014-06-11 03:01:13 +04:00
* The RT_MUTEX_HAS_WAITERS bit can have a transitional state
* as explained at the top of this file if and only if :
2006-06-27 13:54:53 +04:00
*
2014-06-11 03:01:13 +04:00
* - There is a lock owner . The caller must fixup the
* transient state if it does a trylock or leaves the lock
* function due to a signal or timeout .
*
* - @ task acquires the lock and there are no other
* waiters . This is undone in rt_mutex_set_owner ( @ task ) at
* the end of this function .
2006-06-27 13:54:53 +04:00
*/
mark_rt_mutex_waiters ( lock ) ;
2014-06-11 03:01:13 +04:00
/*
* If @ lock has an owner , give up .
*/
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
if ( rt_mutex_owner ( lock ) )
2006-06-27 13:54:53 +04:00
return 0 ;
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
/*
2014-06-11 03:01:13 +04:00
* If @ waiter ! = NULL , @ task has already enqueued the waiter
2015-05-19 20:24:57 +03:00
* into @ lock waiter tree . If @ waiter = = NULL then this is a
2014-06-11 03:01:13 +04:00
* trylock attempt .
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
*/
2014-06-11 03:01:13 +04:00
if ( waiter ) {
2021-08-16 00:29:23 +03:00
struct rt_mutex_waiter * top_waiter = rt_mutex_top_waiter ( lock ) ;
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
2014-06-11 03:01:13 +04:00
/*
2021-08-16 00:29:23 +03:00
* If waiter is the highest priority waiter of @ lock ,
* or allowed to steal it , take it over .
2014-06-11 03:01:13 +04:00
*/
2021-08-16 00:29:23 +03:00
if ( waiter = = top_waiter | | rt_mutex_steal ( waiter , top_waiter ) ) {
/*
* We can acquire the lock . Remove the waiter from the
* lock waiters tree .
*/
rt_mutex_dequeue ( lock , waiter ) ;
} else {
return 0 ;
}
2014-06-11 03:01:13 +04:00
} else {
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
/*
2014-06-11 03:01:13 +04:00
* If the lock has waiters already we check whether @ task is
* eligible to take over the lock .
*
* If there are no other waiters , @ task can acquire
* the lock . @ task - > pi_blocked_on is NULL , so it does
* not need to be dequeued .
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
*/
if ( rt_mutex_has_waiters ( lock ) ) {
2021-08-16 00:29:23 +03:00
/* Check whether the trylock can steal it. */
if ( ! rt_mutex_steal ( task_to_waiter ( task ) ,
rt_mutex_top_waiter ( lock ) ) )
2014-06-11 03:01:13 +04:00
return 0 ;
/*
* The current top waiter stays enqueued . We
* don ' t have to change anything in the lock
* waiters order .
*/
} else {
/*
* No waiters . Take the lock without the
* pi_lock dance . @ task - > pi_blocked_on is NULL
* and we have no waiters to enqueue in @ task
2015-05-19 20:24:57 +03:00
* pi waiters tree .
2014-06-11 03:01:13 +04:00
*/
goto takeit ;
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
}
}
2014-06-11 03:01:13 +04:00
/*
* Clear @ task - > pi_blocked_on . Requires protection by
* @ task - > pi_lock . Redundant operation for the @ waiter = = NULL
* case , but conditionals are more expensive than a redundant
* store .
*/
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & task - > pi_lock ) ;
2014-06-11 03:01:13 +04:00
task - > pi_blocked_on = NULL ;
/*
* Finish the lock acquisition . @ task is the new owner . If
* other waiters exist we have to insert the highest priority
2015-05-19 20:24:57 +03:00
* waiter into @ task - > pi_waiters tree .
2014-06-11 03:01:13 +04:00
*/
if ( rt_mutex_has_waiters ( lock ) )
rt_mutex_enqueue_pi ( task , rt_mutex_top_waiter ( lock ) ) ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & task - > pi_lock ) ;
2014-06-11 03:01:13 +04:00
takeit :
/*
* This either preserves the RT_MUTEX_HAS_WAITERS bit if there
* are still waiters or clears it .
*/
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
rt_mutex_set_owner ( lock , task ) ;
2006-06-27 13:54:53 +04:00
return 1 ;
}
/*
* Task blocks on lock .
*
* Prepare waiter and propagate pi chain
*
2016-01-13 13:25:38 +03:00
* This must be called with lock - > wait_lock held and interrupts disabled
2006-06-27 13:54:53 +04:00
*/
2021-08-16 00:27:58 +03:00
static int __sched task_blocks_on_rt_mutex ( struct rt_mutex_base * lock ,
2021-03-26 18:29:40 +03:00
struct rt_mutex_waiter * waiter ,
struct task_struct * task ,
2021-08-16 00:28:58 +03:00
struct ww_acquire_ctx * ww_ctx ,
2021-03-26 18:29:40 +03:00
enum rtmutex_chainwalk chwalk )
2006-06-27 13:54:53 +04:00
{
2006-07-03 11:25:41 +04:00
struct task_struct * owner = rt_mutex_owner ( lock ) ;
2006-06-27 13:54:53 +04:00
struct rt_mutex_waiter * top_waiter = waiter ;
2021-08-16 00:27:58 +03:00
struct rt_mutex_base * next_lock ;
2006-09-29 12:59:44 +04:00
int chain_walk = 0 , res ;
2006-06-27 13:54:53 +04:00
2017-03-23 17:56:13 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
2014-05-22 07:25:39 +04:00
/*
* Early deadlock detection . We really don ' t want the task to
* enqueue on itself just to untangle the mess later . It ' s not
* only an optimization . We drop the locks , so another waiter
* can come in before the chain walk detects the deadlock . So
* the other will detect the deadlock and return - EDEADLOCK ,
* which is wrong , as the other waiter is not in a deadlock
* situation .
2021-11-29 20:46:46 +03:00
*
* Except for ww_mutex , in that case the chain walk must already deal
* with spurious cycles , see the comments at [ 3 ] and [ 6 ] .
2014-05-22 07:25:39 +04:00
*/
2021-11-29 20:46:46 +03:00
if ( owner = = task & & ! ( build_ww_mutex ( ) & & ww_ctx ) )
2014-05-22 07:25:39 +04:00
return - EDEADLK ;
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & task - > pi_lock ) ;
2009-04-04 00:40:12 +04:00
waiter - > task = task ;
2006-06-27 13:54:53 +04:00
waiter - > lock = lock ;
2021-08-16 00:28:30 +03:00
waiter_update_prio ( waiter , task ) ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
waiter_clone_prio ( waiter , task ) ;
2006-06-27 13:54:53 +04:00
/* Get the top priority waiter on the lock */
if ( rt_mutex_has_waiters ( lock ) )
top_waiter = rt_mutex_top_waiter ( lock ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_enqueue ( lock , waiter ) ;
2006-06-27 13:54:53 +04:00
2009-04-04 00:40:12 +04:00
task - > pi_blocked_on = waiter ;
2006-06-27 13:54:53 +04:00
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & task - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
2021-08-16 00:28:58 +03:00
if ( build_ww_mutex ( ) & & ww_ctx ) {
struct rt_mutex * rtm ;
/* Check whether the waiter should back out immediately */
rtm = container_of ( lock , struct rt_mutex , rtmutex ) ;
res = __ww_mutex_add_waiter ( waiter , rtm , ww_ctx ) ;
2021-08-25 13:33:14 +03:00
if ( res ) {
raw_spin_lock ( & task - > pi_lock ) ;
rt_mutex_dequeue ( lock , waiter ) ;
task - > pi_blocked_on = NULL ;
raw_spin_unlock ( & task - > pi_lock ) ;
2021-08-16 00:28:58 +03:00
return res ;
2021-08-25 13:33:14 +03:00
}
2021-08-16 00:28:58 +03:00
}
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
if ( ! owner )
return 0 ;
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & owner - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
if ( waiter = = rt_mutex_top_waiter ( lock ) ) {
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_dequeue_pi ( owner , top_waiter ) ;
rt_mutex_enqueue_pi ( owner , waiter ) ;
2006-06-27 13:54:53 +04:00
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rt_mutex_adjust_prio ( lock , owner ) ;
2006-09-29 12:59:44 +04:00
if ( owner - > pi_blocked_on )
chain_walk = 1 ;
2014-05-22 07:25:47 +04:00
} else if ( rt_mutex_cond_detect_deadlock ( waiter , chwalk ) ) {
2006-09-29 12:59:44 +04:00
chain_walk = 1 ;
2014-06-05 13:16:12 +04:00
}
2006-09-29 12:59:44 +04:00
2014-06-05 13:16:12 +04:00
/* Store the lock on which owner is blocked or NULL */
next_lock = task_blocked_on_lock ( owner ) ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & owner - > pi_lock ) ;
2014-06-05 13:16:12 +04:00
/*
* Even if full deadlock detection is on , if the owner is not
* blocked itself , we can avoid finding this out in the chain
* walk .
*/
if ( ! chain_walk | | ! next_lock )
2006-06-27 13:54:53 +04:00
return 0 ;
2006-09-29 12:59:44 +04:00
/*
* The owner can ' t disappear while holding a lock ,
* so the owner struct is protected by wait_lock .
* Gets dropped in rt_mutex_adjust_prio_chain ( ) !
*/
get_task_struct ( owner ) ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
2014-05-22 07:25:47 +04:00
res = rt_mutex_adjust_prio_chain ( owner , chwalk , lock ,
2014-06-05 13:16:12 +04:00
next_lock , waiter , task ) ;
2006-06-27 13:54:53 +04:00
2016-01-13 13:25:38 +03:00
raw_spin_lock_irq ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
return res ;
}
/*
2015-05-19 20:24:57 +03:00
* Remove the top waiter from the current tasks pi waiter tree and
2015-05-19 20:24:55 +03:00
* queue it up .
2006-06-27 13:54:53 +04:00
*
2016-01-13 13:25:38 +03:00
* Called with lock - > wait_lock held and interrupts disabled .
2006-06-27 13:54:53 +04:00
*/
2021-08-16 00:28:09 +03:00
static void __sched mark_wakeup_next_waiter ( struct rt_wake_q_head * wqh ,
2021-08-16 00:27:58 +03:00
struct rt_mutex_base * lock )
2006-06-27 13:54:53 +04:00
{
struct rt_mutex_waiter * waiter ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & current - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
waiter = rt_mutex_top_waiter ( lock ) ;
/*
2017-03-23 17:56:11 +03:00
* Remove it from current - > pi_waiters and deboost .
*
* We must in fact deboost here in order to ensure we call
* rt_mutex_setprio ( ) to update p - > pi_top_task before the
* task unblocks .
2006-06-27 13:54:53 +04:00
*/
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_dequeue_pi ( current , waiter ) ;
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rt_mutex_adjust_prio ( lock , current ) ;
2006-06-27 13:54:53 +04:00
2014-06-11 22:44:04 +04:00
/*
* As we are waking up the top waiter , and the waiter stays
* queued on the lock until it gets the lock , this lock
* obviously has waiters . Just set the bit here and this has
* the added benefit of forcing all new tasks into the
* slow path making sure no task of lower priority than
* the top waiter can steal this lock .
*/
lock - > owner = ( void * ) RT_MUTEX_HAS_WAITERS ;
2006-06-27 13:54:53 +04:00
2017-03-23 17:56:11 +03:00
/*
* We deboosted before waking the top waiter task such that we don ' t
* run two tasks with the ' same ' priority ( and ensure the
* p - > pi_top_task pointer points to a blocked task ) . This however can
* lead to priority inversion if we would get preempted after the
* deboost but before waking our donor task , hence the preempt_disable ( )
* before unlock .
*
2021-08-16 00:28:09 +03:00
* Pairs with preempt_enable ( ) in rt_mutex_wake_up_q ( ) ;
2017-03-23 17:56:11 +03:00
*/
preempt_disable ( ) ;
2021-08-16 00:28:09 +03:00
rt_mutex_wake_q_add ( wqh , waiter ) ;
2017-03-23 17:56:11 +03:00
raw_spin_unlock ( & current - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
}
2021-08-16 00:28:12 +03:00
static int __sched __rt_mutex_slowtrylock ( struct rt_mutex_base * lock )
{
int ret = try_to_take_rt_mutex ( lock , current , NULL ) ;
/*
* try_to_take_rt_mutex ( ) sets the lock waiters bit
* unconditionally . Clean this up .
*/
2022-12-02 13:02:23 +03:00
fixup_rt_mutex_waiters ( lock , true ) ;
2021-08-16 00:28:12 +03:00
return ret ;
}
/*
* Slow path try - lock function :
*/
static int __sched rt_mutex_slowtrylock ( struct rt_mutex_base * lock )
{
unsigned long flags ;
int ret ;
/*
* If the lock already has an owner we fail to get the lock .
* This can be done without taking the @ lock - > wait_lock as
* it is only being read , and this is a trylock anyway .
*/
if ( rt_mutex_owner ( lock ) )
return 0 ;
/*
* The mutex has currently no owner . Lock the wait lock and try to
* acquire the lock . We use irqsave here to support early boot calls .
*/
raw_spin_lock_irqsave ( & lock - > wait_lock , flags ) ;
ret = __rt_mutex_slowtrylock ( lock ) ;
raw_spin_unlock_irqrestore ( & lock - > wait_lock , flags ) ;
return ret ;
}
static __always_inline int __rt_mutex_trylock ( struct rt_mutex_base * lock )
{
if ( likely ( rt_mutex_cmpxchg_acquire ( lock , NULL , current ) ) )
return 1 ;
return rt_mutex_slowtrylock ( lock ) ;
}
/*
* Slow path to release a rt - mutex .
*/
static void __sched rt_mutex_slowunlock ( struct rt_mutex_base * lock )
{
DEFINE_RT_WAKE_Q ( wqh ) ;
unsigned long flags ;
/* irqsave required to support early boot calls */
raw_spin_lock_irqsave ( & lock - > wait_lock , flags ) ;
debug_rt_mutex_unlock ( lock ) ;
/*
* We must be careful here if the fast path is enabled . If we
* have no waiters queued we cannot set owner to NULL here
* because of :
*
* foo - > lock - > owner = NULL ;
* rtmutex_lock ( foo - > lock ) ; < - fast path
* free = atomic_dec_and_test ( foo - > refcnt ) ;
* rtmutex_unlock ( foo - > lock ) ; < - fast path
* if ( free )
* kfree ( foo ) ;
* raw_spin_unlock ( foo - > lock - > wait_lock ) ;
*
* So for the fastpath enabled kernel :
*
* Nothing can set the waiters bit as long as we hold
* lock - > wait_lock . So we do the following sequence :
*
* owner = rt_mutex_owner ( lock ) ;
* clear_rt_mutex_waiters ( lock ) ;
* raw_spin_unlock ( & lock - > wait_lock ) ;
* if ( cmpxchg ( & lock - > owner , owner , 0 ) = = owner )
* return ;
* goto retry ;
*
* The fastpath disabled variant is simple as all access to
* lock - > owner is serialized by lock - > wait_lock :
*
* lock - > owner = NULL ;
* raw_spin_unlock ( & lock - > wait_lock ) ;
*/
while ( ! rt_mutex_has_waiters ( lock ) ) {
/* Drops lock->wait_lock ! */
if ( unlock_rt_mutex_safe ( lock , flags ) = = true )
return ;
/* Relock the rtmutex and try again */
raw_spin_lock_irqsave ( & lock - > wait_lock , flags ) ;
}
/*
* The wakeup next waiter path does not suffer from the above
* race . See the comments there .
*
* Queue the next waiter for wakeup once we release the wait_lock .
*/
mark_wakeup_next_waiter ( & wqh , lock ) ;
raw_spin_unlock_irqrestore ( & lock - > wait_lock , flags ) ;
rt_mutex_wake_up_q ( & wqh ) ;
}
static __always_inline void __rt_mutex_unlock ( struct rt_mutex_base * lock )
{
if ( likely ( rt_mutex_cmpxchg_release ( lock , current , NULL ) ) )
return ;
rt_mutex_slowunlock ( lock ) ;
}
2021-08-16 00:29:25 +03:00
# ifdef CONFIG_SMP
static bool rtmutex_spin_on_owner ( struct rt_mutex_base * lock ,
struct rt_mutex_waiter * waiter ,
struct task_struct * owner )
{
bool res = true ;
rcu_read_lock ( ) ;
for ( ; ; ) {
/* If owner changed, trylock again. */
if ( owner ! = rt_mutex_owner ( lock ) )
break ;
/*
* Ensure that @ owner is dereferenced after checking that
* the lock owner still matches @ owner . If that fails ,
* @ owner might point to freed memory . If it still matches ,
* the rcu_read_lock ( ) ensures the memory stays valid .
*/
barrier ( ) ;
/*
* Stop spinning when :
* - the lock owner has been scheduled out
* - current is not longer the top waiter
* - current is requested to reschedule ( redundant
* for CONFIG_PREEMPT_RCU = y )
* - the VCPU on which owner runs is preempted
*/
2021-12-03 10:59:34 +03:00
if ( ! owner_on_cpu ( owner ) | | need_resched ( ) | |
2021-12-18 12:57:03 +03:00
! rt_mutex_waiter_is_top_waiter ( lock , waiter ) ) {
2021-08-16 00:29:25 +03:00
res = false ;
break ;
}
cpu_relax ( ) ;
}
rcu_read_unlock ( ) ;
return res ;
}
# else
static bool rtmutex_spin_on_owner ( struct rt_mutex_base * lock ,
struct rt_mutex_waiter * waiter ,
struct task_struct * owner )
{
return false ;
}
# endif
2021-08-16 00:28:12 +03:00
# ifdef RT_MUTEX_BUILD_MUTEX
/*
* Functions required for :
* - rtmutex , futex on all kernels
* - mutex and rwsem substitutions on RT kernels
*/
2006-06-27 13:54:53 +04:00
/*
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
* Remove a waiter from a lock and give up
2006-06-27 13:54:53 +04:00
*
2021-08-16 00:28:12 +03:00
* Must be called with lock - > wait_lock held and interrupts disabled . It must
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
* have just failed to try_to_take_rt_mutex ( ) .
2006-06-27 13:54:53 +04:00
*/
2021-08-16 00:27:58 +03:00
static void __sched remove_waiter ( struct rt_mutex_base * lock ,
2021-03-26 18:29:40 +03:00
struct rt_mutex_waiter * waiter )
2006-06-27 13:54:53 +04:00
{
2014-06-07 11:36:13 +04:00
bool is_top_waiter = ( waiter = = rt_mutex_top_waiter ( lock ) ) ;
2006-07-03 11:25:41 +04:00
struct task_struct * owner = rt_mutex_owner ( lock ) ;
2021-08-16 00:27:58 +03:00
struct rt_mutex_base * next_lock ;
2006-06-27 13:54:53 +04:00
2017-03-23 17:56:13 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & current - > pi_lock ) ;
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 17:43:43 +04:00
rt_mutex_dequeue ( lock , waiter ) ;
2006-06-27 13:54:53 +04:00
current - > pi_blocked_on = NULL ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & current - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
2014-06-07 11:36:13 +04:00
/*
* Only update priority if the waiter was the highest priority
* waiter of the lock and there is an owner to update .
*/
if ( ! owner | | ! is_top_waiter )
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
return ;
2016-01-13 13:25:38 +03:00
raw_spin_lock ( & owner - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
2014-06-07 11:36:13 +04:00
rt_mutex_dequeue_pi ( owner , waiter ) ;
2006-06-27 13:54:53 +04:00
2014-06-07 11:36:13 +04:00
if ( rt_mutex_has_waiters ( lock ) )
rt_mutex_enqueue_pi ( owner , rt_mutex_top_waiter ( lock ) ) ;
2006-06-27 13:54:53 +04:00
locking/rtmutex: Fix task->pi_waiters integrity
Henry reported that rt_mutex_adjust_prio_check() has an ordering
problem and puts the lie to the comment in [7]. Sharing the sort key
between lock->waiters and owner->pi_waiters *does* create problems,
since unlike what the comment claims, holding [L] is insufficient.
Notably, consider:
A
/ \
M1 M2
| |
B C
That is, task A owns both M1 and M2, B and C block on them. In this
case a concurrent chain walk (B & C) will modify their resp. sort keys
in [7] while holding M1->wait_lock and M2->wait_lock. So holding [L]
is meaningless, they're different Ls.
This then gives rise to a race condition between [7] and [11], where
the requeue of pi_waiters will observe an inconsistent tree order.
B C
(holds M1->wait_lock, (holds M2->wait_lock,
holds B->pi_lock) holds A->pi_lock)
[7]
waiter_update_prio();
...
[8]
raw_spin_unlock(B->pi_lock);
...
[10]
raw_spin_lock(A->pi_lock);
[11]
rt_mutex_enqueue_pi();
// observes inconsistent A->pi_waiters
// tree order
Fixing this means either extending the range of the owner lock from
[10-13] to [6-13], with the immediate problem that this means [6-8]
hold both blocked and owner locks, or duplicating the sort key.
Since the locking in chain walk is horrible enough without having to
consider pi_lock nesting rules, duplicate the sort key instead.
By giving each tree their own sort key, the above race becomes
harmless, if C sees B at the old location, then B will correct things
(if they need correcting) when it walks up the chain and reaches A.
Fixes: fb00aca47440 ("rtmutex: Turn the plist into an rb-tree")
Reported-by: Henry Wu <triangletrap12@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Henry Wu <triangletrap12@gmail.com>
Link: https://lkml.kernel.org/r/20230707161052.GF2883469%40hirez.programming.kicks-ass.net
2023-07-07 17:19:09 +03:00
rt_mutex_adjust_prio ( lock , owner ) ;
2006-06-27 13:54:53 +04:00
2014-06-07 11:36:13 +04:00
/* Store the lock on which owner is blocked or NULL */
next_lock = task_blocked_on_lock ( owner ) ;
2006-09-29 12:59:44 +04:00
2016-01-13 13:25:38 +03:00
raw_spin_unlock ( & owner - > pi_lock ) ;
2006-06-27 13:54:53 +04:00
2014-06-07 11:36:13 +04:00
/*
* Don ' t walk the chain , if the owner task is not blocked
* itself .
*/
2014-06-05 13:16:12 +04:00
if ( ! next_lock )
2006-06-27 13:54:53 +04:00
return ;
2006-09-29 12:59:44 +04:00
/* gets dropped in rt_mutex_adjust_prio_chain()! */
get_task_struct ( owner ) ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
2014-05-22 07:25:47 +04:00
rt_mutex_adjust_prio_chain ( owner , RT_MUTEX_MIN_CHAINWALK , lock ,
next_lock , NULL , current ) ;
2006-06-27 13:54:53 +04:00
2016-01-13 13:25:38 +03:00
raw_spin_lock_irq ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
}
2009-04-04 00:40:12 +04:00
/**
2021-08-16 00:28:00 +03:00
* rt_mutex_slowlock_block ( ) - Perform the wait - wake - try - to - take loop
2009-04-04 00:40:12 +04:00
* @ lock : the rt_mutex to take
2021-08-16 00:28:58 +03:00
* @ ww_ctx : WW mutex context pointer
2009-04-04 00:40:12 +04:00
* @ state : the state the task should block in ( TASK_INTERRUPTIBLE
2016-01-13 13:25:38 +03:00
* or TASK_UNINTERRUPTIBLE )
2009-04-04 00:40:12 +04:00
* @ timeout : the pre - initialized and started timer , or NULL for none
* @ waiter : the pre - initialized rt_mutex_waiter
*
2016-01-13 13:25:38 +03:00
* Must be called with lock - > wait_lock held and interrupts disabled
2006-06-27 13:54:53 +04:00
*/
2021-08-16 00:28:00 +03:00
static int __sched rt_mutex_slowlock_block ( struct rt_mutex_base * lock ,
2021-08-16 00:28:58 +03:00
struct ww_acquire_ctx * ww_ctx ,
2021-08-16 00:28:00 +03:00
unsigned int state ,
struct hrtimer_sleeper * timeout ,
struct rt_mutex_waiter * waiter )
2006-06-27 13:54:53 +04:00
{
2021-08-16 00:28:58 +03:00
struct rt_mutex * rtm = container_of ( lock , struct rt_mutex , rtmutex ) ;
2021-08-16 00:29:25 +03:00
struct task_struct * owner ;
2006-06-27 13:54:53 +04:00
int ret = 0 ;
for ( ; ; ) {
/* Try to acquire the lock: */
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
if ( try_to_take_rt_mutex ( lock , current , waiter ) )
2006-06-27 13:54:53 +04:00
break ;
2021-03-26 18:29:44 +03:00
if ( timeout & & ! timeout - > task ) {
ret = - ETIMEDOUT ;
break ;
}
if ( signal_pending_state ( state , current ) ) {
ret = - EINTR ;
break ;
2006-06-27 13:54:53 +04:00
}
2021-08-16 00:28:58 +03:00
if ( build_ww_mutex ( ) & & ww_ctx ) {
ret = __ww_mutex_check_kill ( rtm , waiter , ww_ctx ) ;
if ( ret )
break ;
}
2021-08-16 00:29:25 +03:00
if ( waiter = = rt_mutex_top_waiter ( lock ) )
owner = rt_mutex_owner ( lock ) ;
else
owner = NULL ;
2016-01-13 13:25:38 +03:00
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
2021-08-16 00:29:25 +03:00
if ( ! owner | | ! rtmutex_spin_on_owner ( lock , waiter , owner ) )
2023-09-08 19:22:52 +03:00
rt_mutex_schedule ( ) ;
2006-06-27 13:54:53 +04:00
2016-01-13 13:25:38 +03:00
raw_spin_lock_irq ( & lock - > wait_lock ) ;
2006-06-27 13:54:53 +04:00
set_current_state ( state ) ;
}
2015-02-02 09:16:24 +03:00
__set_current_state ( TASK_RUNNING ) ;
2009-04-04 00:40:12 +04:00
return ret ;
}
2021-03-26 18:29:40 +03:00
static void __sched rt_mutex_handle_deadlock ( int res , int detect_deadlock ,
struct rt_mutex_waiter * w )
2014-06-05 14:34:23 +04:00
{
/*
* If the result is not - EDEADLOCK or the caller requested
* deadlock detection , nothing to do here .
*/
if ( res ! = - EDEADLOCK | | detect_deadlock )
return ;
2021-08-16 00:28:58 +03:00
if ( build_ww_mutex ( ) & & w - > ww_ctx )
return ;
2014-06-05 14:34:23 +04:00
/*
2021-03-22 04:35:05 +03:00
* Yell loudly and stop the task right here .
2014-06-05 14:34:23 +04:00
*/
2021-03-26 18:29:32 +03:00
WARN ( 1 , " rtmutex deadlock detected \n " ) ;
2014-06-05 14:34:23 +04:00
while ( 1 ) {
set_current_state ( TASK_INTERRUPTIBLE ) ;
2023-09-08 19:22:52 +03:00
rt_mutex_schedule ( ) ;
2014-06-05 14:34:23 +04:00
}
}
2021-08-16 00:28:00 +03:00
/**
* __rt_mutex_slowlock - Locking slowpath invoked with lock : : wait_lock held
* @ lock : The rtmutex to block lock
2021-08-16 00:28:58 +03:00
* @ ww_ctx : WW mutex context pointer
2021-08-16 00:28:00 +03:00
* @ state : The task state for sleeping
* @ chwalk : Indicator whether full or partial chainwalk is requested
* @ waiter : Initializer waiter for blocking
2009-04-04 00:40:12 +04:00
*/
2021-08-16 00:28:00 +03:00
static int __sched __rt_mutex_slowlock ( struct rt_mutex_base * lock ,
2021-08-16 00:28:58 +03:00
struct ww_acquire_ctx * ww_ctx ,
2021-08-16 00:28:00 +03:00
unsigned int state ,
enum rtmutex_chainwalk chwalk ,
struct rt_mutex_waiter * waiter )
2009-04-04 00:40:12 +04:00
{
2021-08-16 00:28:58 +03:00
struct rt_mutex * rtm = container_of ( lock , struct rt_mutex , rtmutex ) ;
struct ww_mutex * ww = ww_container_of ( rtm ) ;
2021-08-16 00:28:00 +03:00
int ret ;
2009-04-04 00:40:12 +04:00
2021-08-16 00:28:00 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
2009-04-04 00:40:12 +04:00
/* Try to acquire the lock again: */
2021-08-16 00:28:58 +03:00
if ( try_to_take_rt_mutex ( lock , current , NULL ) ) {
if ( build_ww_mutex ( ) & & ww_ctx ) {
__ww_mutex_check_waiters ( rtm , ww_ctx ) ;
ww_mutex_lock_acquired ( ww , ww_ctx ) ;
}
2009-04-04 00:40:12 +04:00
return 0 ;
2021-08-16 00:28:58 +03:00
}
2009-04-04 00:40:12 +04:00
set_current_state ( state ) ;
2022-03-22 21:57:09 +03:00
trace_contention_begin ( lock , LCB_F_RT ) ;
2021-08-16 00:28:58 +03:00
ret = task_blocks_on_rt_mutex ( lock , waiter , current , ww_ctx , chwalk ) ;
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 12:09:41 +03:00
if ( likely ( ! ret ) )
2021-08-16 00:28:58 +03:00
ret = rt_mutex_slowlock_block ( lock , ww_ctx , state , NULL , waiter ) ;
if ( likely ( ! ret ) ) {
/* acquired the lock */
if ( build_ww_mutex ( ) & & ww_ctx ) {
if ( ! ww_ctx - > is_wait_die )
__ww_mutex_check_waiters ( rtm , ww_ctx ) ;
ww_mutex_lock_acquired ( ww , ww_ctx ) ;
}
} else {
2015-02-27 19:57:09 +03:00
__set_current_state ( TASK_RUNNING ) ;
2021-08-16 00:28:00 +03:00
remove_waiter ( lock , waiter ) ;
rt_mutex_handle_deadlock ( ret , chwalk , waiter ) ;
2014-06-05 14:34:23 +04:00
}
2006-06-27 13:54:53 +04:00
/*
* try_to_take_rt_mutex ( ) sets the waiter bit
* unconditionally . We might have to fix that up .
*/
2022-12-02 13:02:23 +03:00
fixup_rt_mutex_waiters ( lock , true ) ;
2022-03-22 21:57:09 +03:00
trace_contention_end ( lock , ret ) ;
2021-08-16 00:28:00 +03:00
return ret ;
}
2006-06-27 13:54:53 +04:00
2021-08-16 00:28:00 +03:00
static inline int __rt_mutex_slowlock_locked ( struct rt_mutex_base * lock ,
2021-08-16 00:28:58 +03:00
struct ww_acquire_ctx * ww_ctx ,
2021-08-16 00:28:00 +03:00
unsigned int state )
{
struct rt_mutex_waiter waiter ;
int ret ;
rt_mutex_init_waiter ( & waiter ) ;
2021-08-16 00:28:58 +03:00
waiter . ww_ctx = ww_ctx ;
2006-06-27 13:54:53 +04:00
2021-08-16 00:28:58 +03:00
ret = __rt_mutex_slowlock ( lock , ww_ctx , state , RT_MUTEX_MIN_CHAINWALK ,
& waiter ) ;
2006-06-27 13:54:53 +04:00
debug_rt_mutex_free_waiter ( & waiter ) ;
2021-08-16 00:28:00 +03:00
return ret ;
}
/*
* rt_mutex_slowlock - Locking slowpath invoked when fast path fails
* @ lock : The rtmutex to block lock
2021-08-16 00:28:58 +03:00
* @ ww_ctx : WW mutex context pointer
2021-08-16 00:28:00 +03:00
* @ state : The task state for sleeping
*/
static int __sched rt_mutex_slowlock ( struct rt_mutex_base * lock ,
2021-08-16 00:28:58 +03:00
struct ww_acquire_ctx * ww_ctx ,
2021-08-16 00:28:00 +03:00
unsigned int state )
{
unsigned long flags ;
int ret ;
2023-09-08 19:22:52 +03:00
/*
* Do all pre - schedule work here , before we queue a waiter and invoke
* PI - - any such work that trips on rtlock ( PREEMPT_RT spinlock ) would
* otherwise recurse back into task_blocks_on_rt_mutex ( ) through
* rtlock_slowlock ( ) and will then enqueue a second waiter for this
* same task and things get really confusing real fast .
*/
rt_mutex_pre_schedule ( ) ;
2021-08-16 00:28:00 +03:00
/*
* Technically we could use raw_spin_ [ un ] lock_irq ( ) here , but this can
* be called in early boot if the cmpxchg ( ) fast path is disabled
* ( debug , no architecture support ) . In this case we will acquire the
* rtmutex with lock - > wait_lock held . But we cannot unconditionally
* enable interrupts in that early boot case . So we need to use the
* irqsave / restore variants .
*/
raw_spin_lock_irqsave ( & lock - > wait_lock , flags ) ;
2021-08-16 00:28:58 +03:00
ret = __rt_mutex_slowlock_locked ( lock , ww_ctx , state ) ;
2021-08-16 00:28:00 +03:00
raw_spin_unlock_irqrestore ( & lock - > wait_lock , flags ) ;
2023-09-08 19:22:52 +03:00
rt_mutex_post_schedule ( ) ;
2006-06-27 13:54:53 +04:00
return ret ;
}
2021-08-16 00:27:58 +03:00
static __always_inline int __rt_mutex_lock ( struct rt_mutex_base * lock ,
2021-08-16 00:27:57 +03:00
unsigned int state )
{
2023-09-08 19:22:53 +03:00
lockdep_assert ( ! current - > pi_blocked_on ) ;
2023-09-08 19:22:49 +03:00
if ( likely ( rt_mutex_try_acquire ( lock ) ) )
2021-08-16 00:27:57 +03:00
return 0 ;
2021-08-16 00:28:58 +03:00
return rt_mutex_slowlock ( lock , NULL , state ) ;
2021-08-16 00:27:57 +03:00
}
2021-08-16 00:28:12 +03:00
# endif /* RT_MUTEX_BUILD_MUTEX */
2021-08-16 00:28:25 +03:00
# ifdef RT_MUTEX_BUILD_SPINLOCKS
/*
* Functions required for spin / rw_lock substitution on RT kernels
*/
/**
* rtlock_slowlock_locked - Slow path lock acquisition for RT locks
* @ lock : The underlying RT mutex
*/
static void __sched rtlock_slowlock_locked ( struct rt_mutex_base * lock )
{
struct rt_mutex_waiter waiter ;
2021-08-16 00:29:25 +03:00
struct task_struct * owner ;
2021-08-16 00:28:25 +03:00
lockdep_assert_held ( & lock - > wait_lock ) ;
if ( try_to_take_rt_mutex ( lock , current , NULL ) )
return ;
rt_mutex_init_rtlock_waiter ( & waiter ) ;
/* Save current state and set state to TASK_RTLOCK_WAIT */
current_save_and_set_rtlock_wait_state ( ) ;
2022-03-22 21:57:09 +03:00
trace_contention_begin ( lock , LCB_F_RT ) ;
2021-08-16 00:28:58 +03:00
task_blocks_on_rt_mutex ( lock , & waiter , current , NULL , RT_MUTEX_MIN_CHAINWALK ) ;
2021-08-16 00:28:25 +03:00
for ( ; ; ) {
/* Try to acquire the lock again */
if ( try_to_take_rt_mutex ( lock , current , & waiter ) )
break ;
2021-08-16 00:29:25 +03:00
if ( & waiter = = rt_mutex_top_waiter ( lock ) )
owner = rt_mutex_owner ( lock ) ;
else
owner = NULL ;
2021-08-16 00:28:25 +03:00
raw_spin_unlock_irq ( & lock - > wait_lock ) ;
2021-08-16 00:29:25 +03:00
if ( ! owner | | ! rtmutex_spin_on_owner ( lock , & waiter , owner ) )
schedule_rtlock ( ) ;
2021-08-16 00:28:25 +03:00
raw_spin_lock_irq ( & lock - > wait_lock ) ;
set_current_state ( TASK_RTLOCK_WAIT ) ;
}
/* Restore the task state */
current_restore_rtlock_saved_state ( ) ;
/*
* try_to_take_rt_mutex ( ) sets the waiter bit unconditionally .
* We might have to fix that up :
*/
2022-12-02 13:02:23 +03:00
fixup_rt_mutex_waiters ( lock , true ) ;
2021-08-16 00:28:25 +03:00
debug_rt_mutex_free_waiter ( & waiter ) ;
2022-03-22 21:57:09 +03:00
trace_contention_end ( lock , 0 ) ;
2021-08-16 00:28:25 +03:00
}
static __always_inline void __sched rtlock_slowlock ( struct rt_mutex_base * lock )
{
unsigned long flags ;
raw_spin_lock_irqsave ( & lock - > wait_lock , flags ) ;
rtlock_slowlock_locked ( lock ) ;
raw_spin_unlock_irqrestore ( & lock - > wait_lock , flags ) ;
}
# endif /* RT_MUTEX_BUILD_SPINLOCKS */