kernel/locking/rtmutex.c
Source file repositories/reference/linux-study-clean/kernel/locking/rtmutex.c
File Facts
- System
- Linux kernel
- Corpus path
kernel/locking/rtmutex.c- Extension
.c- Size
- 54084 bytes
- Lines
- 1927
- Domain
- Core OS
- Bucket
- Scheduler, Processes, Timers, Sync, And Syscalls
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/sched.hlinux/sched/debug.hlinux/sched/deadline.hlinux/sched/signal.hlinux/sched/rt.hlinux/sched/wake_q.hlinux/ww_mutex.htrace/events/lock.hrtmutex_common.hlock_events.hww_mutex.h
Detected Declarations
function Copyrightfunction __ww_mutex_check_waitersfunction freefunction rt_mutex_set_ownerfunction rt_mutex_clear_ownerfunction clear_rt_mutex_waitersfunction fixup_rt_mutex_waitersfunction enqueuefunction lockfunction rt_mutex_cmpxchg_acquirefunction rt_mutex_try_acquirefunction rt_mutex_cmpxchg_releasefunction mark_rt_mutex_waitersfunction unlock_rt_mutex_safefunction rt_mutex_cmpxchg_acquirefunction rt_mutex_try_acquirefunction rt_mutex_cmpxchg_releasefunction mark_rt_mutex_waitersfunction unlock_rt_mutex_safefunction __waiter_priofunction waiter_update_priofunction waiter_clone_priofunction rt_waiter_node_lessfunction rt_waiter_node_equalfunction rt_mutex_stealfunction __waiter_lessfunction rt_mutex_enqueuefunction rt_mutex_dequeuefunction __pi_waiter_lessfunction rt_mutex_enqueue_pifunction rt_mutex_dequeue_pifunction rt_mutex_adjust_priofunction rt_mutex_wake_q_add_taskfunction rt_mutex_wake_q_addfunction rt_mutex_wake_up_qfunction rt_mutex_cond_detect_deadlockfunction rt_mutex_adjust_prio_chainfunction Thefunction task_blocked_on_lockfunction task_blocks_on_rt_mutexfunction mark_wakeup_next_waiterfunction __rt_mutex_slowtrylockfunction rt_mutex_slowtrylockfunction __rt_mutex_trylockfunction rt_mutex_slowunlockfunction __rt_mutex_unlockfunction rtmutex_spin_on_ownerfunction rtmutex_spin_on_owner
Annotated Snippet
* 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);
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);
}
}
/*
* We can speed up the acquire/release, if there's no debugging state to be
* set up.
*/
#ifndef CONFIG_DEBUG_RT_MUTEXES
static __always_inline bool rt_mutex_cmpxchg_acquire(struct rt_mutex_base *lock,
struct task_struct *old,
struct task_struct *new)
{
return try_cmpxchg_acquire(&lock->owner, &old, new);
}
static __always_inline bool rt_mutex_try_acquire(struct rt_mutex_base *lock)
{
return rt_mutex_cmpxchg_acquire(lock, NULL, current);
}
static __always_inline bool rt_mutex_cmpxchg_release(struct rt_mutex_base *lock,
struct task_struct *old,
struct task_struct *new)
{
return try_cmpxchg_release(&lock->owner, &old, new);
}
/*
* 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.
*/
static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock)
{
unsigned long *p = (unsigned long *) &lock->owner;
unsigned long owner, new;
owner = READ_ONCE(*p);
do {
new = owner | RT_MUTEX_HAS_WAITERS;
} while (!try_cmpxchg_relaxed(p, &owner, new));
/*
* 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();
}
/*
Annotation
- Immediate include surface: `linux/sched.h`, `linux/sched/debug.h`, `linux/sched/deadline.h`, `linux/sched/signal.h`, `linux/sched/rt.h`, `linux/sched/wake_q.h`, `linux/ww_mutex.h`, `trace/events/lock.h`.
- Detected declarations: `function Copyright`, `function __ww_mutex_check_waiters`, `function free`, `function rt_mutex_set_owner`, `function rt_mutex_clear_owner`, `function clear_rt_mutex_waiters`, `function fixup_rt_mutex_waiters`, `function enqueue`, `function lock`, `function rt_mutex_cmpxchg_acquire`.
- Atlas domain: Core OS / Scheduler, Processes, Timers, Sync, And Syscalls.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.