]> www.infradead.org Git - users/jedix/linux-maple.git/commit
sched: Fix race between yield_to() and try_to_wake_up()
authorTianchen Ding <dtcccc@linux.alibaba.com>
Tue, 31 Dec 2024 05:50:20 +0000 (13:50 +0800)
committerPeter Zijlstra <peterz@infradead.org>
Mon, 13 Jan 2025 13:10:22 +0000 (14:10 +0100)
commit5d808c78d97251af1d3a3e4f253e7d6c39fd871e
treebb0ce985f97fb70f3bb3945d9d54bfe96a4a30bb
parent7c8cd569ff66755f17b0c0c03a9d8df1b6f3e9ed
sched: Fix race between yield_to() and try_to_wake_up()

We met a SCHED_WARN in set_next_buddy():
  __warn_printk
  set_next_buddy
  yield_to_task_fair
  yield_to
  kvm_vcpu_yield_to [kvm]
  ...

After a short dig, we found the rq_lock held by yield_to() may not
be exactly the rq that the target task belongs to. There is a race
window against try_to_wake_up().

         CPU0                             target_task

                                        blocking on CPU1
   lock rq0 & rq1
   double check task_rq == p_rq, ok
                                        woken to CPU2 (lock task_pi & rq2)
                                        task_rq = rq2
   yield_to_task_fair (w/o lock rq2)

In this race window, yield_to() is operating the task w/o the correct
lock. Fix this by taking task pi_lock first.

Fixes: d95f41220065 ("sched: Add yield_to(task, preempt) functionality")
Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20241231055020.6521-1-dtcccc@linux.alibaba.com
kernel/sched/syscalls.c