From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 878AD7DA88 for ; Tue, 31 Dec 2024 05:50:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.98 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735624239; cv=none; b=dciGpp4HWZ5YQ8yUK7fmA+EPw/ynZ4dXyyXfVBCTkD9MDiRS16ti1Iw/Qv1whcZK1YjQc7GlAsqiAKNnkvbia2WXndDp0QN63QKtPcP8A1rcKLgpWGxqv9MlSejgaYp4rqxDMgbn3Vw44fvZI1hHx84KRtw4EgzE+RA3zA5BJwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735624239; c=relaxed/simple; bh=fe8WFq43QUPnRRJctLxzRXiywUGIWtsw4na3wiXyeh4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=c9voSxWB/oHVtmR/EZzTr6Vo/SuAOeD8zntxMmvLmyKykw8RjDShYPLtXSwSYJ7NuZH/aO1YbYv/wZ7RxJKVyR35isWw+jHsVZ3EuFXXgCmZDeRzQq2qtGGyKjTKeDDjecMfRcngUQgmWXQlUu/U187uX0+nP8Aw//UPqa/Y+Jw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=p1M2J2UQ; arc=none smtp.client-ip=115.124.30.98 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="p1M2J2UQ" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1735624228; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=FHp8jNYlNQybXD5aq+vgr4+3Rx7msvZB76oSt6bsFsI=; b=p1M2J2UQrfu6Ld8i65phYyQhU/3+yfyXvrCqwB76KY12gBxWSaLoNa9vjw1cpEeyAaE3fT1al/R2W/9rERItX2G1HyIMopycOiaODbro1LBAe+vJMLyZssPhitdbQ5yOYriBtXjh/HiCIgLCufpEkiV0mUDpIJX8kFxlGJLyEcY= Received: from localhost.localdomain(mailfrom:dtcccc@linux.alibaba.com fp:SMTPD_---0WMcyX4i_1735624220 cluster:ay36) by smtp.aliyun-inc.com; Tue, 31 Dec 2024 13:50:27 +0800 From: Tianchen Ding To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Marcelo Tosatti , Mike Galbraith , Rik van Riel Subject: [PATCH] sched: Fix race between yield_to() and try_to_wake_up() Date: Tue, 31 Dec 2024 13:50:20 +0800 Message-Id: <20241231055020.6521-1-dtcccc@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 lock. Fix this by taking task pi_lock first. Fixes: d95f41220065 ("sched: Add yield_to(task, preempt) functionality") Signed-off-by: Tianchen Ding --- kernel/sched/syscalls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c index ff0e5ab4e37c..943406c4ee86 100644 --- a/kernel/sched/syscalls.c +++ b/kernel/sched/syscalls.c @@ -1433,7 +1433,7 @@ int __sched yield_to(struct task_struct *p, bool preempt) struct rq *rq, *p_rq; int yielded = 0; - scoped_guard (irqsave) { + scoped_guard (raw_spinlock_irqsave, &p->pi_lock) { rq = this_rq(); again: -- 2.39.3