proxy_reset_donor() warning from sched_proxy_block_task() when p is curr

proxy_reset_donor() warning from sched_proxy_block_task() when p is curr

[Tejun Heo]

Hello,

sched_proxy_block_task() calls proxy_reset_donor() whenever p is the
donor, without checking that p isn't also curr. proxy_reset_donor() then
triggers its WARN_ON_ONCE(rq->donor == rq->curr):

  WARNING: kernel/sched/core.c:3809 at proxy_reset_donor+0x129/0x140, CPU#3: flip/1539
  Call Trace:
   sched_proxy_block_task+0xa1/0x170
   scx_prepare_setscheduler+0xcf/0xe0
   __sched_setscheduler+0x6d6/0xb60
   do_sched_setscheduler+0x105/0x160
   __x64_sys_sched_setscheduler+0x18/0x30
   do_syscall_64+0xec/0x420
   entry_SYSCALL_64_after_hwframe+0x76/0x7e

p is a sched_ext task under a scheduler with SCX_OPS_ENQ_BLOCKED. It
blocks on a mutex in __schedule() and stays queued as a retained donor,
still curr and donor until the pick finishes. The pick goes through
sched_ext dispatch, which drops the rq lock while ops.dispatch() moves a
task from another CPU.

In that window, sched_setscheduler(p, SCHED_EXT) from another CPU takes
p's pi_lock and rq lock and reaches sched_proxy_block_task() with p both
curr and donor. I also hit it, rarely, through scx_sub_enable_workfn()
-> scx_prepare_task_sched_change().

Nothing else went wrong in my runs. The pick sees p dequeued and carries
on.

It reproduces reliably within a minute in an 8-CPU VM on
sched_ext/for-7.4-fixes (2227a34ff7bf) with:

  scx_qmap -X -s 100
  stress-ng --cpu 4 --cpu-method loop
  modprobe locktorture torture_type=mutex_lock nested_locks=8 \
      long_hold=2 nwriters_stress=16

and a small program that flips the lock_torture_wr threads between
SCHED_EXT and SCHED_OTHER with sched_setscheduler() as fast as it can.

Thanks.

--
tejun