[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ea88aa65-0ddd-474f-bce1-51ea67445cf1@linux.alibaba.com>
Date: Tue, 31 Dec 2024 13:56:03 +0800
From: Tianchen Ding <dtcccc@...ux.alibaba.com>
To: linux-kernel@...r.kernel.org
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
Mel Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>, Mike Galbraith <efault@....de>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH] sched: Fix race between yield_to() and try_to_wake_up()
On 2024/12/31 13:50, Tianchen Ding wrote:
> 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 currect
Sorry... a typo for "correct"
Powered by blists - more mailing lists