Re: [PATCH 01/12] sched/core: Avoid false migration warning for proxy donors

[Andrea Righi]

On Tue, Jul 21, 2026 at 12:00:45AM -0700, John Stultz wrote:
> On Mon, Jul 20, 2026 at 11:33 PM Andrea Righi <arighi@xxxxxxxxxx> wrote:
> >
> > Proxy execution can move a blocked donor's scheduling context to the
> > lock owner's CPU even when the donor is migration-disabled. The donor
> > does not execute there, and its original execution CPU remains recorded
> > in wake_cpu.
> >
> > set_task_cpu() warns unconditionally for migration-disabled tasks, so a
> > subsequent proxy migration or the wakeup path returning the donor home
> > triggers a false positive. Moving a blocked scheduling context does not
> > violate the migration-disabled execution context.
> >
> > Exclude blocked proxy donors from the warning. The proxy wakeup path
> > restores an executable placement before clearing the blocked state.
> >
> > This is a preparatory fix for enabling proxy execution together with
> > sched_ext.
> >
> > Signed-off-by: Andrea Righi <arighi@xxxxxxxxxx>
> 
> Nice catch on this!
> 
> I'm wondering why I've not tripped this myself yet. Is
> migration_disabled set more often in the sched_ext paths? Or was there
> a specific workload that you hit this with?

I triggered this with a modified scx_cosmos with proxy-exec support (option
--proxy-exec): https://github.com/sched-ext/scx/tree/cosmos-proxy-exec

This was the trace, triggered when scx_cosmos was stopped:

  [   12.992201] WARNING: kernel/sched/core.c:3444 at set_task_cpu+0x1d3/0x280, CPU#6: kworker/u65:1/103
  [   12.992387] Modules linked in:
  [   12.992593] CPU: 6 UID: 0 PID: 103 Comm: kworker/u65:1 Not tainted 7.1.0-virtme #3 PREEMPT(full)
  [   12.993012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  [   12.993075] Workqueue: events_unbound bpf_map_free_deferred
  [   12.993139] RIP: 0010:set_task_cpu+0x1d3/0x280
  [   12.993285] Code: 14 89 6b 64 c6 83 09 17 00 00 01 5b 41 5e 41 5f 5d c3 cc cc cc cc cc 90 0f 0b 90 66 83 bb 80 05 00 00 00 0f 84 f8 fe
  ff ff 90 <0f> 0b 90 e9 ef fe ff ff 48 8d 3d ce 12 4c 02 67 48 0f b9 3a e9 03
  [   12.993656] RSP: 0018:ffffc900003f7cf8 EFLAGS: 00010002
  [   12.994642] RAX: 0000000000000000 RBX: ffff888100c6c800 RCX: 0000000000000046
  [   12.994756] RDX: ffffc900003f7d2c RSI: ffff888100c6d338 RDI: ffff888100c454d0
  [   12.994860] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
  [   12.994956] R10: 000000000000003b R11: ffffffff813f5c30 R12: 0000000000000000
  [   12.995055] R13: ffff888100c6d320 R14: ffff888100c44800 R15: 0000000000000206
  [   12.995167] FS:  0000000000000000(0000) GS:ffff8882b380a000(0000) knlGS:0000000000000000
  [   12.995273] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [   12.995354] CR2: 00007fe19b902000 CR3: 000000000364c000 CR4: 0000000000750ef0
  [   12.995462] PKRU: 55555554
  [   12.995502] Call Trace:
  [   12.995540]  <TASK>
  [   12.995580]  try_to_wake_up+0x360/0x6f0
  [   12.995640]  __mutex_unlock_slowpath+0x32f/0x540
  [   12.995716]  ? bpf_local_storage_map_free+0x84/0x280
  [   12.995789]  ? process_scheduled_works+0x225/0x520
  [   12.995861]  bpf_local_storage_map_free+0x257/0x280
  [   12.995934]  bpf_map_free+0x84/0x110
  [   12.995992]  process_scheduled_works+0x271/0x520
  [   12.996071]  worker_thread+0x1e1/0x300
  [   12.996133]  ? __pfx_worker_thread+0x10/0x10
  [   12.996206]  kthread+0x10c/0x140
  [   12.996266]  ? __pfx_kthread+0x10/0x10
  [   12.996319]  ret_from_fork+0x189/0x330
  [   12.996378]  ? __pfx_kthread+0x10/0x10
  [   12.996435]  ret_from_fork_asm+0x1a/0x30
  [   12.996500]  </TASK>

Looking at bpf_local_storage_map_free(), I think I triggered this warning,
because bpf_map_free() calls migrate_disable() around map->ops->map_free() and
the deferred map-free workers can block on mutexes while migration is disabled.
Then proxy-exec moves the worker to the mutex owner's CPU and when the mutex is
released, ttwu returns the worker to its pinned CPU and trips the set_task_cpu()
warning.

> 
> Acked-by: John Stultz <jstultz@xxxxxxxxxx>
> 
> thanks
> -john

Thanks,
-Andrea