From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azon11012010.outbound.protection.outlook.com [52.101.48.10]) (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 654DC42BC42 for ; Tue, 14 Jul 2026 20:46:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.48.10 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784062008; cv=fail; b=JBMxkOU2xLwHCfaUkITXIUQeqWPylGcIIxn8C79YralYSBom9wvPR56uoIUiF/SpkjyxZSdYFCTpLqcfdSXdOdujnr4kGFvvNQGW8lBJRnLuc+lJNOM8yIQhnIyJEOr5TA//QwWt5uhLcqGvqxKV/Zrpum4hBJmmmWV2YhbY1RM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784062008; c=relaxed/simple; bh=+14NgdPBVM7bwptJDWrB6qsAdcgmoJbiBYDtlrzpq/Q=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=XbcSA8Uk6y/cG8W3ccGVtNBJuM2wzXkEamn9e1RJwqsjGD/AmEWUO6i7hACdrR14z0SDXdb7q/hhkCy4fFuEfKizx3738eFUgqOGdiOoc1ASRj35LUIMdB21xBVm+NzsRx7J9tRUe876tI12AKhjPGOcjY2OCxDshSNjp/2oBhs= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=Po2tOp/4; arc=fail smtp.client-ip=52.101.48.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="Po2tOp/4" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ETPmyKapOgLi7FS9l4+UpW8nNBF/WBxOXDcccnpEIfh5AkfVaLkDsm6vdKMh7m00gRet3LHFTV00Ef/ylpN3ayEoBPYnldeD3F6OghHmpVaJoMNwxaOWfwOBTGbBId3H/U8XUROuL9VqbA/zHrh9CjxDxkI5s8bLZJBHGw26FBaY/1Aac7y8NZd4JQbopElY9k+fyA1T6xwBKaH+eCwbt20/ajbXeHtCiITCxwCfqpWEhYjypB7K2ZpwI/Zi619T6MX3br1YkEwpyIzTsdueKP1YQ7jfGyoe6sh3eF/sCSr7ffnvrB3rdbQKeCn4lx5SXPE0apP7axCzQrsSm64zsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R/CWqkdEm9i9WbF7pEL1CBctDmGh36tFrdu7FnMQQWQ=; b=CGeCabrOS/gblrgQZsgqidMS7rT72jMXvVm9FDNtr7zBqSrWAhdr48svilecCdgPY5MpIPG9HJkPYPkxGx2Gjarat/c63nVfSSudAWlg+YvWCWLzd4xrYo7N81aAs026HIpR91+UldkQLSOjMtvDisX944/LvK5x2kBK+YO4YjRiwBGg65nTbz4aE9T6g5HJgvAZfKuuHRooiWoD8Pz27oPygia9hqaY8je/hbVJTDM5VpK+qdMNdiKTtf7AMpirlB/GVFIpMfqzO/4x8ko32UN8BJf4+2SOiGUVGU97gd6nm1SKblK9/HEf4kzNHxDyOuP9HcRQsh5cN0jns2iMCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R/CWqkdEm9i9WbF7pEL1CBctDmGh36tFrdu7FnMQQWQ=; b=Po2tOp/4jnfefycL3oYp3cYrpyfQlfkjE+58uXpSw5XPEx1PExrND3jIkPcEKyzJk4xWyWvj+Gilg1xchvN4yy+rj+jzZeCVEis8ub3JWUoUR6CJzlWMqMZ47fXiD2oqwH1ldHDpVUVfP0WJ4BWBqlF3oBDRvjItqyIwySG5Rq0= Received: from DS7P222CA0018.NAMP222.PROD.OUTLOOK.COM (2603:10b6:8:2e::33) by SJ2PR12MB9240.namprd12.prod.outlook.com (2603:10b6:a03:563::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.10; Tue, 14 Jul 2026 20:46:36 +0000 Received: from DS1PEPF00017097.namprd05.prod.outlook.com (2603:10b6:8:2e:cafe::4f) by DS7P222CA0018.outlook.office365.com (2603:10b6:8:2e::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Tue, 14 Jul 2026 20:46:35 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by DS1PEPF00017097.mail.protection.outlook.com (10.167.18.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Tue, 14 Jul 2026 20:46:35 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Tue, 14 Jul 2026 15:46:35 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Tue, 14 Jul 2026 13:46:35 -0700 Received: from [172.31.184.125] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Tue, 14 Jul 2026 15:46:32 -0500 Message-ID: <31e87e29-0e24-4448-a30e-c0d05dec2e2c@amd.com> Date: Wed, 15 Jul 2026 02:16:30 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] sched/proxy_exec: Break cyclic proxy chains by deactivating blocked tasks To: , John Stultz CC: Peter Zijlstra , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , "Mel Gorman" , Valentin Schneider , References: <1df0e505-add4-4b7d-8e09-bc52402da617@amd.com> <20260714152220.4046736-1-soolaugust@gmail.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260714152220.4046736-1-soolaugust@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF00017097:EE_|SJ2PR12MB9240:EE_ X-MS-Office365-Filtering-Correlation-Id: 32c8e37c-f88a-4ea0-939f-08dee1e8fed9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|82310400026|7416014|376014|23010399003|4143699003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: VaWLAuFJAMECqkhCr87e+eN/+gJuZKR8jXYjfiV9FurBERwo0r/8Xs4FBAUCniwxQvaWMXojblShb6nzpJWpqfmICGpqyM+SG6FZyHrBL88zXI1+BEcyN9a7yHDebVT27GcPBETjoMtbcURe763vMgfjMZi2FtqqYv8aHC8vl9i404oeegcf2slhmC/XSDR8BehDL3oWbGd/N9dW9PY2Pd7e4VjBZ41E1/3e2O1e5jKXSq37crHGE/kYn/fc7dbsMVhhyTiMSmtmOQGUGo995Wwhan0rfk6xNUTVRirigfczDt3GHEr/hlaNnhm3MEy//kC2DuRb7v//wZcEMaKB0I7x+1heXt120mlPvxfdLhqC3Ufpd7iRsndhyqj8nPSvyEAEmGP0vcR4gTINkXM9HT501qQsjb1E+ihsyYVwG4P/Nil1rO91B58/s+NpYVk1cmJcEqqUV+kgWZ/UjHRougxKD7wuRrhi1ZbD1oWXBYFQB2ih7caWVcUIP/s4gzmAKhhQCf7NbOApuDzQA8SJXg/Ln5gAJ38D55m1bOyuON7RGYzj9mvPKvMwXyTawd/iFiL8OegZ7gExd2sbF+UddyI1AR/QSveIMvx0mEQ4+bYBCBnhElRsqgGB9rQ3lCjtwiI16+6uIBlJN1EDFJvi4LAtcEJPMnCH/Ghccs+7AEMXMVHUEX4FaEd05Sjq3YCemDNCxHxZKJhyNobYUQ2YtA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(82310400026)(7416014)(376014)(23010399003)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: gkdkPaSaK3wMCW5fWGqolmLX/eEqH64ffAir2cqmxcmzWj8M1y9kZnMT/3uPTjLh6g1Z/iKKx3+BsKqBUJJM6PhLvnW32SiHMFg6NQ4Zvw0dikX2wpF3OuJRZPvWF2CeMxgC00anqNm1gteN4M7KL5/sShiKiET0S8mOtdQM9zZJJenrORmN8JnJ33VSdryGDRne8DNT1R12pkny6pM8yp+ew2WLkSIHSuvy3NLvfEBAtggqkEPZq+FzoAMMbPXzrJgKwnGzFbCCFfLwy6egC8NBLsFNxBCMKw9uFH7cjqVxndfJyeizPWruI++3IUgW3WhgNwd3WvZJiAHplcTkMgtabtC/JUbb5/anT/lKTlTRaHgeo7Ph+F6wL+AcVQmKOei+ozzIwq+1WQvk2SRZTbG4GxnsDduw2x0DJfiwpXK52vJ7tr3yrC/SJO+Pa8Jy X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2026 20:46:35.6745 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 32c8e37c-f88a-4ea0-939f-08dee1e8fed9 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF00017097.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9240 Hello Zhidao, On 7/14/2026 8:51 PM, soolaugust@gmail.com wrote: > 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 I'm not really a fan of the arbitrary MAX_PROXY_CHAIN_DEPTH. > + > 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) { So let us take a step back. Say you have a genuine case of: A -> B -> C -> D ^ | | | +---------+ donor = A Cycle is somewhere in-between the chain Now, we have a "p->blocked_donor" back link that we can probably leverage to detect this cycle except we don't clear a p->blocked_donor link when find_proxy_task() returns idle or NULL so we can have stale p->blocked_donor links for queued tasks but they are so far harmless. Me goes and thinks ... Since p->blocked_donor isn't used for chain migration yet, does something like below help your deadlock case? (Prepared on top of tip:sched/core; Lightly tested) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 2e7cde033a31..fa1d9443f744 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6874,6 +6874,9 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) struct task_struct *p; int owner_cpu; + /* Increment proxy_pick_seq such that last 4 bits are always set. */ + rq->proxy_pick_seq += 0x10; + /* Follow blocked_on chain. */ for (p = donor; p->is_blocked; p = owner) { /* if its PROXY_WAKING, do return migration or run if current */ @@ -6990,12 +6993,28 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) */ return proxy_resched_idle(rq); } + + /* Cyclic deadlock detection. */ + if (((u64)owner->blocked_donor) & 0xF) { + u64 pick_seq = (u64)owner->blocked_donor; + + /* + * Owner was already seen during this find_proxy_task() loop. + * Deactivate the task since there is a loop in proxy-chain. + */ + if (rq->proxy_pick_seq == pick_seq) { + __clear_task_blocked_on(p, NULL); + goto deactivate; + } + } + /* * OK, now we're absolutely sure @owner is on this * rq, therefore holding @rq->lock is sufficient to * guarantee its existence, as per ttwu_remote(). */ owner->blocked_donor = p; + p->blocked_donor = (void *)rq->proxy_pick_seq; } WARN_ON_ONCE(owner && !owner->on_rq); return owner; @@ -9057,6 +9076,9 @@ void __init sched_init(void) raw_spin_lock_init(&rq->cpu_epoch_lock); rq->cpu_epoch_next = jiffies; #endif +#ifdef CONFIG_SCHED_PROXY_EXEC + rq->proxy_pick_seq = 0xf; +#endif zalloc_cpumask_var_node(&rq->scratch_mask, GFP_KERNEL, cpu_to_node(i)); } diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 26ae13c86b69..452cbcd3a8c5 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -1154,6 +1154,7 @@ struct rq { #ifdef CONFIG_SCHED_PROXY_EXEC struct task_struct __rcu *donor; /* Scheduling context */ struct task_struct __rcu *curr; /* Execution context */ + u64 proxy_pick_seq; /* find_proxy_task() seq */ #else union { struct task_struct __rcu *donor; /* Scheduler context */ --- base-commit: 04998aa54848f15332202d0bea008d2ca1ed1713 This assumes task_struct pointers are 4-bytes aligned. Only rq->curr->blocked_donor matters currently so it should be okay to clobber the rest of the chain. If this is okay, perhaps we can just stash the pick_seq copy in task_struct. Thoughts? > + 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) -- Thanks and Regards, Prateek