From nobody Fri Jun 19 07:51:23 2026 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (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 B400154763 for ; Fri, 24 Apr 2026 07:33:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777016020; cv=none; b=GyQELJ+Zf8lpxLJ049ZMrwlrXjnNakcVlyZk2Qpd+8RNBbIuwOrjlJNMJzVlZn7wOC9zQL1XBKumBSQlgRTxsBGZaoarbORD5l1tF8COWXmp0e3dIj/fCQLJFWGl8cZmHRTrpFzNUNI66V6ofdgfqtZ9cZUQIe5AR6aNnWCIO+A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777016020; c=relaxed/simple; bh=HpznxJ+EaKzBlU0hXuK1Pn9jnl9IgvZrXQYHHMKe8KM=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=e5DASUd5Jljdk9p80mCfEKdWLcAbHuot8SZE2AgIadsiUcBK2DdyC+BwZNJgZ4MNQ9dK79Kib3nLPf6Ro0dGZEKPJlyWOI9zMjRgl2qZyaEdQcafX6eKLS7pYPLSFiavIdYPZYKCBjqvRgPa4eI8uijH208uZSpwAiahv9cgOB4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=o5AHGFCN; arc=none smtp.client-ip=113.46.200.224 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="o5AHGFCN" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=hiOi0+wHuyj0wz8J3m6SXyz4WbUpWRiFP7h8jFGMgFU=; b=o5AHGFCNemVT+x9N3DI6jkwLGWRAeEATCMZF2e/X1PE9XRFh13A5Iy/f8GG0SIJ1YCTwtMrcy B3f/wJyeP0dDWfopZFN4eLLUh4WcJ4RysaIpuxbt3u5pNh9wsbBh8EyKXotlW6hgZMP6rotCXym sKC6H1Qvfx7cqbkkdtXYtww= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4g24KW0D73z1cyQg; Fri, 24 Apr 2026 15:27:11 +0800 (CST) Received: from dggemv706-chm.china.huawei.com (unknown [10.3.19.33]) by mail.maildlp.com (Postfix) with ESMTPS id 0FDCE40561; Fri, 24 Apr 2026 15:33:34 +0800 (CST) Received: from kwepemq100012.china.huawei.com (7.202.195.195) by dggemv706-chm.china.huawei.com (10.3.19.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 24 Apr 2026 15:33:33 +0800 Received: from huawei.com (10.67.175.84) by kwepemq100012.china.huawei.com (7.202.195.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 24 Apr 2026 15:33:33 +0800 From: Zicheng Qu To: , , , , , , , , , , CC: , , Subject: [PATCH] sched/fair: Clear rel_deadline when initializing forked entities Date: Fri, 24 Apr 2026 07:11:13 +0000 Message-ID: <20260424071113.1199600-1-quzicheng@huawei.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemq100012.china.huawei.com (7.202.195.195) Content-Type: text/plain; charset="utf-8" A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set. The failing sequence is: 1. A task is forked while se->rel_deadline is still set. 2. __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline. 3. On the first enqueue, enqueue_entity() calls place_entity(). 4. Because se->rel_deadline is set, place_entity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime. 5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline. 6. If the task later calls sched_yield(), yield_task_fair() advances se->vruntime to se->deadline. 7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight. 8. This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. pick_next_entity() may then return NULL unexpectedly, leading to a later NULL dereference. A captured trace shows the effect clearly. Before yield, the entity's vruntime was around: 9834017729983308 After yield_task_fair() executed: se->vruntime =3D se->deadline the vruntime jumped to: 19668035460670230 and the deadline was later advanced further to: 19668035463470230 This shows that the deadline had already become abnormally large before yield_task_fair() copied it into vruntime. rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline. Fixes: 82e9d0456e06 ("sched/fair: Avoid re-setting virtual deadline on 'mig= rations'") Analyzed-by: Hui Tang Analyzed-by: Zhang Qiao Signed-off-by: Zicheng Qu Reviewed-by: K Prateek Nayak --- kernel/sched/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index da20fb6ea25a..b8871449d3c6 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4458,6 +4458,7 @@ static void __sched_fork(u64 clone_flags, struct task= _struct *p) p->se.nr_migrations =3D 0; p->se.vruntime =3D 0; p->se.vlag =3D 0; + p->se.rel_deadline =3D 0; INIT_LIST_HEAD(&p->se.group_node); =20 /* A delayed task cannot be in clone(). */ --=20 2.34.1