Files
linux/include/linux
John Stultz 2d76226698 sched/locking: Add special p->blocked_on==PROXY_WAKING value for proxy return-migration
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 <jstultz@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://patch.msgid.link/20260324191337.1841376-7-jstultz@google.com
2026-04-03 14:23:40 +02:00
..
2026-02-11 13:44:47 +01:00
2025-10-22 07:54:33 +02:00
2026-01-29 20:21:41 +01:00
2025-12-15 14:33:38 +01:00
2025-09-05 15:06:03 +02:00
2025-07-21 18:18:51 +01:00
2026-01-20 19:44:19 -08:00
2025-07-31 11:28:03 -04:00
2026-02-12 04:23:53 -07:00
2025-11-21 11:21:31 +01:00
2025-09-23 11:13:22 +02:00
2025-12-16 14:40:51 +01:00
2025-10-22 07:55:00 +02:00
2025-11-01 12:44:49 -05:00
2025-12-13 20:04:32 +12:00
2025-08-21 13:58:07 +02:00
2026-02-19 09:12:05 +01:00
2025-12-23 11:23:10 -08:00
2025-10-29 18:28:29 -07:00
2025-09-13 17:32:44 -07:00
2025-08-29 13:39:53 -07:00
2026-01-12 16:52:09 +01:00
2025-11-04 12:36:02 +01:00
2026-02-06 07:29:14 -07:00
2025-10-22 07:53:15 +02:00
2025-09-23 11:13:22 +02:00
2025-06-11 11:57:14 -07:00
2026-01-05 16:43:31 +01:00
2026-01-11 06:09:11 -10:00
2025-07-02 17:18:01 +01:00
2026-01-20 19:24:50 -08:00
2026-01-26 19:03:47 -08:00
2025-11-23 12:30:40 +01:00
2025-12-29 11:53:38 +01:00
2026-01-26 20:02:27 -08:00
2025-09-17 15:58:29 -04:00
2025-06-17 18:18:46 -07:00
2025-11-04 19:10:33 -08:00
2025-09-23 13:28:20 -04:00
2025-11-05 23:58:20 +01:00
2025-11-03 17:41:17 +01:00
2025-11-11 10:01:30 +01:00
2026-02-20 17:31:55 -05:00
2026-01-30 11:34:34 +00:00
2025-09-13 16:55:07 -07:00
2026-02-10 11:39:31 +01:00
2026-02-10 11:39:30 +01:00
2026-01-11 06:09:11 -10:00
2025-08-24 11:41:11 -06:00
2025-07-01 12:29:29 +02:00
2025-10-30 18:35:26 +01:00
2025-10-24 21:39:27 +02:00
2025-10-31 10:16:23 +01:00
2025-11-27 14:24:30 -08:00
2025-11-18 17:52:54 +01:00
2026-01-11 06:09:11 -10:00
2025-11-28 09:21:18 -07:00
2026-01-05 16:43:30 +01:00
2026-01-31 14:22:57 -08:00
2026-01-14 12:04:34 +01:00
2026-01-06 17:06:03 -08:00
2026-01-11 06:09:11 -10:00
2025-11-03 17:41:18 +01:00
2026-01-20 19:24:47 -08:00
2026-01-30 18:26:59 -08:00