From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazon11012031.outbound.protection.outlook.com [52.101.53.31]) (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 8F4FE288B8 for ; Wed, 15 Jul 2026 03:01:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.53.31 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784084488; cv=fail; b=cyh+Lb6Zdtuam1PLY23O3i3AHpnVGgFo5hZW0/273bvx2di+uIA99ifpT+UkarEUVa/B0fI5YNnqAdx2JYMzHlEP6iZyIphhfGGMirsH8TpiIQedAlHs9qyqOCXRHHvnsTRbGzlXH7kvaaypILx16dV16Vj5gX0AdQK+CTS0ZwI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784084488; c=relaxed/simple; bh=yKQx2UFU55E74mcGZd5sujnHCcHfexD6GNrOdan/aCY=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=lxP4g5dL8S2MykBm6oR2CegIBAs+Ed5L7ZT1Lbto4+DNuecYV/VA5h3jJpFg62ZGVzOQhGuYe2MgkeQQZW1XYzk88kgB4J54k4uuhdHT/O+XjfmG6ZRF6h39R6JtIEB9iyNFOpvKYqyHeUAmbKRm/W9a/XKZnLmUg+TfpvgA1sQ= 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=TtkEkW5B; arc=fail smtp.client-ip=52.101.53.31 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="TtkEkW5B" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ccS4PBePbfQpwxd6/aE5kVufPn4GI5Cp06xCQkUaZccwZxz0u4fSgnT3myv5WAeZiw5p00ldtctu9qsj+kZYlVs1Fb+VulSJlj8ic8ueJGuVb0l2e+sLR4WdoR0RGSepgcVqldnDyK+MYSkIVKU0iC9PFG16NIJXMF/hF+Zr9n5Cbnh3jr1QM84wFQnIxil6CFNnnth8W5NYkrUPBcdBKYxxJfarBXz+6N7BHDbgaq4cx0SJYu+XKJkkP304wrR2jA8hSP6j+TnicWV5ildAa4uZ8pIuHV+e7e5DWiDWR/Qc2NjAixdr7b/cVOVTtKveG7XqaNOtgzLje/u5BpL9JA== 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=Ad/DHdUD0esEaiV4FCPFKaIZdCib8Lel7KmrwJmyLKQ=; b=R3umy4pBKQPKVCRYnULs0QmoIIxRdOtSetubpvk+w8IjMy104Ldk6emYGbHDNCGD6JVX01v2N7ae7ciKY7AseD2K2BNjSKHhcYx982xragWv5L86BX/tyAevPIo6cEVi4/oqEWgxnAK4teH2TNNWe4l95K9/jZMhrHksKh8wMjLU8G9FUZrMslgtKvRdg7u9tUgezrqSy94oyam3u2snxX19xG0FPnCTND4wPvVToX/4JS+eXhuKw6YXob3kI4IjfqX01UuGRa+SYfYEt+02Xb7krk4qQoKcdAd7HmWzoj/pyiYhh9JDc1a2YmxN8Cv1G8Iql48YzyqZKBwRR/ulxQ== 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=Ad/DHdUD0esEaiV4FCPFKaIZdCib8Lel7KmrwJmyLKQ=; b=TtkEkW5BFqCe2NeUAglzZApfJMxbLXeo3idwzsr1Uzsuxc90J3cu6+RFFFE5KZ3mNaKZdzoDAFcTp0ZZEpx4lzJuPwsrhTs0g2Thu146qw0/QFuOBE4M9Y7QcqKJbdj9CVmXl7tbwGcEwFjKoY4/ZZOukBzz7huEMFy9cxBH6eQ= Received: from MN2PR03CA0024.namprd03.prod.outlook.com (2603:10b6:208:23a::29) by SN7PR12MB8789.namprd12.prod.outlook.com (2603:10b6:806:34b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.10; Wed, 15 Jul 2026 03:01:22 +0000 Received: from BL6PEPF00020E62.namprd04.prod.outlook.com (2603:10b6:208:23a:cafe::79) by MN2PR03CA0024.outlook.office365.com (2603:10b6:208:23a::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Wed, 15 Jul 2026 03:01:21 +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=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by BL6PEPF00020E62.mail.protection.outlook.com (10.167.249.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.9 via Frontend Transport; Wed, 15 Jul 2026 03:01:21 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) 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 22:01:21 -0500 Received: from [10.136.35.249] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Tue, 14 Jul 2026 22:01:18 -0500 Message-ID: <05a66f9b-dc82-4ada-a074-afaa7628c089@amd.com> Date: Wed, 15 Jul 2026 08:31:17 +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> <178408304702.304643.2084630008424110320@gmail.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <178408304702.304643.2084630008424110320@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF00020E62:EE_|SN7PR12MB8789:EE_ X-MS-Office365-Filtering-Correlation-Id: 86bae107-45be-449f-f76c-08dee21d599d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|7416014|376014|30052699003|36860700016|23010399003|18002099003|22082099003|11063799006|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: gV8OxRgK3b8fDV+su9wKVChEy4wZptxz5k1d9hRQwKdQByh/wqeYuZV9mmxwSoDJPOX8kevI0K5+h0kCNKXMNTq8GmxHG/zyUKEdEaKi4tLIPCEi6HZz4F9ZXInzbkoeervU7Fuknfiv7zs6u4zD7ZS9rFRhZ4R7rLfrD3MamXVd6UlDM73lBxJwkjFpssEtLBg8TDi3bwf6CObEYNPhZk2jUb7vNJiR0HROPg2TZg6GJJ3atep/V0S+yjyXTRnJ9dzj3O1BCcOQQygVdYf4MwHhkkjz2exio7fR9ykR4jDnb/VSpXdyuxAOdi3F2o4ccm7RbWCbxeGarwdYmNVUBnxQ/cU90RPfz/BRUpr1TDZBkXY57xJ17FBDENTkyZRRHYQyqnafox3xNEQEgfiyAjxbv1tnLxMhuUbtJMv6Tortfo7XCHpnJx42DctKcT3anBIc92HPW01bRoBQk4e85KMqgSin7VEyN4wWxITAU9OOGt6Ye/ES4y8/LESkFZTZdWyk1V65VRQoguOiwEpvcrZPe7tSBYnxrZkn31A6XxD/skldk89ySResmOY000IWV/BVeUbI2Z5gTCX3QxZdfdsOOSnW90BZ9anj605D1T9fwih5gJk3caEtlRTY0ZJrXyx8jHLTDKGaWdMSlfcaM0W+7gaiL7J339qI6WpbzoqWffPpkF6dGtobIA/CWcaOO2YXddxALVMNm9pYEmt9HQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(7416014)(376014)(30052699003)(36860700016)(23010399003)(18002099003)(22082099003)(11063799006)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: bAIRj/gDFfcWY3mfvHtsK9P/OC0K0tGXGmvo6zt2IZeina70IHRGkvEWFsBZqdEyDyuKsnq+7IpyrUWrd2O2x8JXKzeCLCys7IHst8qEvV6Oqo8tJmJwkGu9j/lw6x+LT9GvC024/ar/uENPci/VQ6MQeO4v7H3NJHDH3jbyjw7Omnd0qjdy76b9v05xI+TLhwSE8QwYLgI8IclhH9iMDsCOTzOTfu/8TkKOdpLAKIyjBYPRTP7mfIu/aRQANuFuk3eg9uatpYdPvoO5sT6aCwujEGou89GgBMX1Manl+QgUUmEH0eySjj8Jr7Wnf16anE/y9q6LZr7MIdn+wCChVjBWgG56yutlDMdvwYvvIATgxKyaR9g+5drWJUbb9sMme+/aS+pvQ+10FmmFDCHQdXdCXAUqu4QLwyNvK1C4qOSFLExc6ze05XGt7x1rOUoc X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2026 03:01:21.8296 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 86bae107-45be-449f-f76c-08dee21d599d 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=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF00020E62.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8789 Hello Zhidao, On 7/15/2026 8:07 AM, soolaugust@gmail.com wrote: > Thanks Prateek. > >> I'm not really a fan of the arbitrary MAX_PROXY_CHAIN_DEPTH. > > Agreed. It was only a guard rail, not a real fix. I'll drop it in v3 > and switch to a proper cycle check. > >> This only catches cycles that come back to the original donor. > > Right. The owner == donor check only catches cycles that include the > original donor, so it misses loops in the middle of the chain, like > your A -> B -> C -> D -> B example. > >> Maybe we can use the blocked_donor backlink as a visited marker? > > The basic idea makes sense, but I'd rather not overload blocked_donor. > That field is already the donor-stack backlink, and keeping it as a > plain task pointer seems easier to reason about as the proxy-exec model > grows to more primitives. > > So for v3 I'll likely use an explicit per-pick seq marker instead. Ack! Sample code was just a PoC to see if it is good enough to solve the hard lockup problem :-) Btw, I realized you'll need to reset this marker on migration, else there is a rare chance of a stale p->blocked_donor pick_seq from an old pick CPU colliding with the pick_seq after migration. For my PoC, this was a good enough solution: diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 452cbcd3a8c5..f5180913c038 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2400,6 +2400,7 @@ static inline void __set_task_cpu(struct task_struct *p, unsigned int cpu) smp_wmb(); WRITE_ONCE(task_thread_info(p)->cpu, cpu); p->wake_cpu = cpu; + p->blocked_donor = NULL; rseq_sched_set_ids_changed(p); #endif /* CONFIG_SMP */ } --- You can make this fit as per your v3 scheme. >> We should probably think about other lock types too. > > Yes, agreed. That's another reason to keep this at the proxy > wait-for-chain level rather than make it mutex-specific. The current > tree still only has mutex-backed blocked_on, but the design is meant to > cover other blocking primitives as well. Ack! I think eventually, blocked_on becomes a struct with a lock_type enum + void* pointer which allows for interpreting the pointer based on the lock_type. I agree p->blocked_donor has other uses with the extended series so it is best to use a separate variable to track the seq_count if we go down that route. I'll let John comment if it is a good idea or not. > > Thanks for the review. I'll rework v3 accordingly. Thanks a ton. -- Thanks and Regards, Prateek