user/sven/linux.git/kernel/locking, branch next/HEAD

Merge branch into tip/master: 'sched/core'

2026-04-09T03:07:36Z

# New commits in sched/core: 985215804dcb ("sched/rt: Cleanup global RT bandwidth functions") 4f70a0456d09 ("sched/rt: Move group schedulability check to sched_rt_global_validate()") 8b016dcec936 ("sched/rt: Skip group schedulable check with rt_group_sched=0") 556146ce5e94 ("sched/fair: Avoid overflow in enqueue_entity()") c6e80201e057 ("sched: Use u64 for bandwidth ratio calculations") 059258b0d424 ("sched/fair: Prevent negative lag increase during delayed dequeue") 2d4cc371baa5 ("sched/fair: Use sched_energy_enabled()") b049b81bdff6 ("sched: Handle blocked-waiter migration (and return migration)") dec9554dc036 ("sched: Move attach_one_task and attach_task helpers to sched.h") 48fda62de67a ("sched: Add logic to zap balance callbacks if we pick again") f9530b318335 ("sched: Add assert_balance_callbacks_empty helper") 2d7622669836 ("sched/locking: Add special p->blocked_on==PROXY_WAKING value for proxy return-migration") 56f4b24267a6 ("sched: Fix modifying donor->blocked on without proper locking") fa4a1ff8ab23 ("locking: Add task::blocked_lock to serialize blocked_on state") f4fe6be82e6d ("sched: Fix potentially missing balancing with Proxy Exec") 37341ec573da ("sched: Minimise repeated sched_proxy_exec() checking") e0ca8991b2de ("sched: Make class_schedulers avoid pushing current, and get rid of proxy_tag_curr()") Signed-off-by: Ingo Molnar

sched/locking: Add special p->blocked_on==PROXY_WAKING value for proxy return-migration

2026-04-03T12:23:40Z

As we add functionality to proxy execution, we may migrate a donor task to a runqueue where it can't run due to cpu affinity. Thus, we must be careful to ensure we return-migrate the task back to a cpu in its cpumask when it becomes unblocked. Peter helpfully provided the following example with pictures: "Suppose we have a ww_mutex cycle: ,-+-* Mutex-1 <-. Task-A ---' | | ,-- Task-B `-> Mutex-2 *-+-' Where Task-A holds Mutex-1 and tries to acquire Mutex-2, and where Task-B holds Mutex-2 and tries to acquire Mutex-1. Then the blocked_on->owner chain will go in circles. Task-A -> Mutex-2 ^ | | v Mutex-1 <- Task-B We need two things: - find_proxy_task() to stop iterating the circle; - the woken task to 'unblock' and run, such that it can back-off and re-try the transaction. Now, the current code [without this patch] does: __clear_task_blocked_on(); wake_q_add(); And surely clearing ->blocked_on is sufficient to break the cycle. Suppose it is Task-B that is made to back-off, then we have: Task-A -> Mutex-2 -> Task-B (no further blocked_on) and it would attempt to run Task-B. Or worse, it could directly pick Task-B and run it, without ever getting into find_proxy_task(). Now, here is a problem because Task-B might not be runnable on the CPU it is currently on; and because !task_is_blocked() we don't get into the proxy paths, so nobody is going to fix this up. Ideally we would have dequeued Task-B alongside of clearing ->blocked_on, but alas, [the lock ordering prevents us from getting the task_rq_lock() and] spoils things." Thus we need more than just a binary concept of the task being blocked on a mutex or not. So allow setting blocked_on to PROXY_WAKING as a special value which specifies the task is no longer blocked, but needs to be evaluated for return migration *before* it can be run. This will then be used in a later patch to handle proxy return-migration. Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Link: https://patch.msgid.link/20260324191337.1841376-7-jstultz@google.com

locking: Add task::blocked_lock to serialize blocked_on state

2026-04-03T12:23:39Z

So far, we have been able to utilize the mutex::wait_lock for serializing the blocked_on state, but when we move to proxying across runqueues, we will need to add more state and a way to serialize changes to this state in contexts where we don't hold the mutex::wait_lock. So introduce the task::blocked_lock, which nests under the mutex::wait_lock in the locking order, and rework the locking to use it. Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Link: https://patch.msgid.link/20260324191337.1841376-5-jstultz@google.com

locking: Add lock context annotations in the spinlock implementation

2026-03-16T12:16:50Z

Make the spinlock implementation compatible with lock context analysis (CONTEXT_ANALYSIS := 1) by adding lock context annotations to the _raw_##op##_...() macros. Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260313171510.230998-4-bvanassche@acm.org

locking/rwsem: Fix logic error in rwsem_del_waiter()

2026-03-16T12:16:48Z

Commit 1ea4b473504b ("locking/rwsem: Remove the list_head from struct rw_semaphore") introduced a logic error in rwsem_del_waiter(). The root cause of this issue is an inconsistency in the return values of __rwsem_del_waiter() and rwsem_del_waiter(). Specifically, __rwsem_del_waiter() returns true when the wait list becomes empty, whereas rwsem_del_waiter() is supposed to return true if the wait list is NOT empty. This caused a null pointer dereference in rwsem_mark_wake() because it was being called when sem->first_waiter was NULL. Fixes: 1ea4b473504b ("locking/rwsem: Remove the list_head from struct rw_semaphore") Reported-by: syzbot+3d2ff92c67127d337463@syzkaller.appspotmail.com Signed-off-by: Andrei Vagin Signed-off-by: Peter Zijlstra (Intel) Tested-by: syzbot+3d2ff92c67127d337463@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260314182607.3343346-1-avagin@google.com

locking/rwsem: Add context analysis

2026-03-08T10:06:53Z

Add compiler context analysis annotations. Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260306101417.GT1282955@noisy.programming.kicks-ass.net

locking/rtmutex: Add context analysis

2026-03-08T10:06:53Z

Add compiler context analysis annotations. Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260121111213.851599178@infradead.org

locking/mutex: Add context analysis

2026-03-08T10:06:53Z

Add compiler context analysis annotations. Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260121111213.745353747@infradead.org

locking/mutex: Remove the list_head from struct mutex

2026-03-08T10:06:52Z

Instead of embedding a list_head in struct mutex, store a pointer to the first waiter. The list of waiters remains a doubly linked list so we can efficiently add to the tail of the list, remove from the front (or middle) of the list. Some of the list manipulation becomes more complicated, but it's a reasonable tradeoff on the slow paths to shrink data structures which embed a mutex like struct file. Some of the debug checks have to be deleted because there's no equivalent to checking them in the new scheme (eg an empty waiter->list now means that it is the only waiter, not that the waiter is no longer on the list). Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260305195545.3707590-4-willy@infradead.org

locking/semaphore: Remove the list_head from struct semaphore

2026-03-08T10:06:52Z

Instead of embedding a list_head in struct semaphore, store a pointer to the first waiter. The list of waiters remains a doubly linked list so we can efficiently add to the tail of the list and remove from the front (or middle) of the list. Some of the list manipulation becomes more complicated, but it's a reasonable tradeoff on the slow paths to shrink data structures which embed a semaphore. Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260305195545.3707590-3-willy@infradead.org