From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5B0E34CFCF for ; Tue, 14 Jul 2026 15:22:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784042561; cv=none; b=KgEPr0N7C7FSDS/TDNBWOg3/tBZ1YMntcxGvhWv6Ty2yAz6oGEhouVi9Jv7znEfaViYr5qBHV7OxV6DwUseXigxWXa87A3mgRnXOe0Q+vX/Ux4cWd8ocIQqTOPtWfnr2jDTKqC8qczibCAxP0Ytas4DUuYGGIM7BE50ArZVsoF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784042561; c=relaxed/simple; bh=Z99Smu0V/lkvWsb0NDrVb3UhglbI09dUvYcLI9cKIzY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LLVy7ApQ1hWVPqbZkw0Bk6Y/j2BOUMMInZNINHWSXyw45HKD8hXcnvfgQaAt4EGnZAXwt8Z2GnNjyac/gaQY3ZSC+u15I45OA5DzAHhxn5xsychm9Ne75SozjpaRltiyZh+fW6EEpoe9OD7XouenOaNFt2dlRO2td//SHd7ZMUw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=l9v0rjU7; arc=none smtp.client-ip=209.85.210.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="l9v0rjU7" Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-848d21bbaffso3466193b3a.0 for ; Tue, 14 Jul 2026 08:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784042559; x=1784647359; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=5L7jaqdoBuyI34SKm2rpLoDGGjtxJV23oOsFfeD+Kqo=; b=l9v0rjU7BnyEoVtN+IPSJvPTuD+NTeiN5NiuJtwlf99lEd68tDEP+qHKgmyQV9GZ31 OlCTObzXJJdWRWbTVuIR/cNcMwiFgiD3lk1tH4ejbrgbf/M4gRS+hfUUYunUfNQRsiNp qZ3NIoO1zNdvIERCiFKMVKYWlglAzuQZz6QcO7dKq1LIye7vG+HnJNtbybrVHPIrkj8s eAfflaYgeGoauW79491hwfOelhDpxGOmjq3kS7sDuy1gnGv6mxQwDWtqWZcSWtdTEDwQ V2BLIALY7gqy2L3DnG/SHBSzAjyp4zbRa9K0Ohv1DG/vON3JfebsYZtY0KUxAy2QQpwS vj8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784042559; x=1784647359; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=5L7jaqdoBuyI34SKm2rpLoDGGjtxJV23oOsFfeD+Kqo=; b=LTz/cNRuG//H3WP4ssSnaxBvAyFh4KTj0MDKm9hzArorgwyZOZ1KmAcZt6EvL28MFj H/K9bfQVB8xoe9LC87K55CyinlCwoVzwf7PcLKdivrjM80sFydO5RgneJTq4v7g3tRmN pAxuYExX4dvQO2iqJ9Vl+sUyj3JUDbB68p42+TdHjadWZ7WTJ2aNOzSXLty9tWfmnKao 7MG5FFTuSZ/suqBSm7tK2NFsRItBagpmm8Twe3VIlpgjCleBJUieFL6cfSJW4nri0XGZ +wkb8Ee/tgZc7Ap3c2hNwBY29LWps1CL5zFz2Y9BVCz0+XawvL5n3MUQzUWlOdGzA6UI eBbQ== X-Forwarded-Encrypted: i=1; AHgh+Rr5iC7y/EaH7krK6lJSdfIcixNplm79A12Yd+F3JnQK21woKPuFxr8QulUgsxdiMNmbhqMNFkuv0wodNu4=@vger.kernel.org X-Gm-Message-State: AOJu0YxwngNgX7KJ2qhRGXgp+/Y1TXxxvdy0TfXHHiuMydF78lyCugDi +1o37JtZQXin09iU0s/3AnoZUSUolh1f7zuQYlif5YlwyYy263I0HL6M X-Gm-Gg: AfdE7ckgbLdA3xHWs2xsDUkU/6+sz51J6oXsln8j7vT4RiUw71/j6kJ7JwQvlai7oCK Z+AH+iqt9r5YArZSsgRrZRmdLcxRymfN7fBtRcFBT7XWEhUgFmvG6NA2OhvBzjyRmryH2s95Mgf 3UAsXd4dMdbrlMluET011Ly3qifUL3m46HVxZeMJBDy6ly2R106JtuGYR48f2l31+jDYQC+M5jS +yTLPWi+yro6PtJot5FDuq4wTVW7x11Srf1dauYMrKEsQN11JvbMDyNlhoMM4p0/2dsuyx/wXAl Ijd4FA1qkEUjWRsPxpsWUqP+JlKboYQtgyTctLo/Rak1Ga2sHRRDKX/mScGN0KzTMXwAjQABzny 32OkaKp0Wu6UwdyAqH/rqdaZFtnr1BYYcKO9o/V85rdjt7YUdTpXbkECQCvH6pIk93WmL7EiH1y ogZyRRazpEzyTzOraUp2bJRyzcacxIheRWbUe7QpoyU5awItGrBMFXM/yGWbCB6XJq1A== X-Received: by 2002:a05:6a00:2e02:b0:848:7b92:8e74 with SMTP id d2e1a72fcca58-84a55894696mr2859726b3a.39.1784042559219; Tue, 14 Jul 2026 08:22:39 -0700 (PDT) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84a4f6bf016sm1643839b3a.28.2026.07.14.08.22.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 08:22:38 -0700 (PDT) From: soolaugust@gmail.com To: K Prateek Nayak , John Stultz Cc: "zhidao su (Xiaomi)" , Peter Zijlstra , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org Subject: [PATCH v2] sched/proxy_exec: Break cyclic proxy chains by deactivating blocked tasks Date: Tue, 14 Jul 2026 23:21:44 +0800 Message-ID: <20260714152220.4046736-1-soolaugust@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <1df0e505-add4-4b7d-8e09-bc52402da617@amd.com> References: <1df0e505-add4-4b7d-8e09-bc52402da617@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "zhidao su (Xiaomi)" find_proxy_task() follows the blocked_on/owner chain for a blocked donor. If the chain forms a cycle, __schedule() can keep walking the same chain while holding rq->lock. A PE cycle reproducer creates two tasks blocked on each other's mutexes. Without a guard, the guest does not complete within a 90s vng timeout. With this change, loading the reproducer reports: sched/pe: deadlock cycle detected, pid 128 and a heartbeat kthread pinned to the same CPU continues to run: pe_cycle_kmod: heartbeat 3 pid 129 Rescheduling idle is not enough here: the same blocked_on relation remains, so the next scheduling pass can select the same donor and re-enter the same cycle. When the walk reaches the original donor again, clear the current blocked_on relation and deactivate that blocked task. Do the same for excessive chain depth after revalidating blocked_on under p->blocked_lock. This removes the task from the proxy-exec runnable-chain selection path and lets the scheduler make progress. Use 1024 as the depth limit to match rtmutex's default max_lock_depth. Signed-off-by: zhidao su (Xiaomi) --- Changes from v1: - Deactivate the blocked task instead of rescheduling idle. - Add direct owner == donor cycle detection. - Raise MAX_PROXY_CHAIN_DEPTH from 64 to 1024. kernel/sched/core.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 2e7cde033a319..cff1a3b58660b 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6724,6 +6724,8 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p, } #ifdef CONFIG_SCHED_PROXY_EXEC +#define MAX_PROXY_CHAIN_DEPTH 1024 + static inline void proxy_set_task_cpu(struct task_struct *p, int cpu) { unsigned int wake_cpu; @@ -6873,6 +6875,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) int this_cpu = cpu_of(rq); struct task_struct *p; int owner_cpu; + int chain_depth = 0; /* Follow blocked_on chain. */ for (p = donor; p->is_blocked; p = owner) { @@ -6905,6 +6908,13 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) return NULL; } + if (++chain_depth > MAX_PROXY_CHAIN_DEPTH) { + WARN_ONCE(1, "sched/pe: proxy chain depth exceeded %d, pid %d\n", + MAX_PROXY_CHAIN_DEPTH, p->pid); + __clear_task_blocked_on(p, NULL); + goto deactivate; + } + if (task_current(rq, p)) curr_in_chain = true; @@ -6923,6 +6933,13 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) goto deactivate; } + if (owner == donor) { + WARN_ONCE(1, "sched/pe: deadlock cycle detected, pid %d\n", + p->pid); + __clear_task_blocked_on(p, NULL); + goto deactivate; + } + if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) { /* XXX Don't handle blocked owners/delayed dequeue yet */ if (curr_in_chain) -- 2.43.0