From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazon11012025.outbound.protection.outlook.com [40.107.200.25]) (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 E937E17D6 for ; Fri, 29 May 2026 07:59:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.200.25 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780041542; cv=fail; b=TI2PCyc/HlJ04GZ8YNvCy9OiHnBlNxQg9ADrmBYXjkQHzwQc0MlkFbx1dXBUzfZEnkR+wx+YcqBUIbpkoZnaOu8lQsHTkeDXyXa26f0oomM97axijUbpSQxycwHI1IhpnJE8/95SFqAay4kUXDYvMrbpOFMN5ZhQoIOxLw3xim0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780041542; c=relaxed/simple; bh=hp7u+1D8q+w89boYyFs3LUU/Q5kixYYze0Uw+e8AgR0=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=DEOeGfiWHGmsmY5pIw+fAbKTdKrKjQCKSbQH0Wz5qkz8ckv+km0a73ZxtD0oB7/x32XGrqaT+FrAs75aSdEAdWuH60pRM18TQzsxqChG70jLexzgP1r7bq8cVJFQLzU7B7+7Gr/ILYf6t9FiUFCEz51U5/B42teLlPE/9Zcirb0= 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=tn8r/5U4; arc=fail smtp.client-ip=40.107.200.25 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="tn8r/5U4" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KLdXsksjEeR0Rrk9Eddqlt41YM+llQbFMdpEdoXGUl+A+Yl21CWahhQHFuaVAVGPaKuVvINwY6f5yKlaRJVTrdjpO0e91/32SNfvmhAAdnis1d8UsIDohEQOeg0gM2Z7kyVUituIOd6hga9uhGvVw/JczcUdFlUUUtbFJwUnQTtfqXehvAOxPwdGjJVXLkbVEcs8U6qWNs+EsqTDv1atYZqV6kt6iRVJ5cIVH+f/C2XFKxhBlCTqD0T8vRKIAF5jfW/ZXXn1nhx3qusogh+Q1uxFhcrhf2hNS2KuwULVQVDhPcMoM7X31Dq4QWVldW7VqvyfCREqcuBoiGB+0PIraw== 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=o8Y+KAlwvIgs/EoD6+wfqVoA2wqLIJcpFkJWsCwuWHQ=; b=Nyz8/2yc/C7xVQ/7fLRtSGIHpXUbnHatHQlEEsT50LT1wwSzgzorVycwyManuLKJA+2De5TB2pPAquKOP8sbfAuBx5cueQ5sAmF6+HQ7FMMla1oY2FI92VvmFbvkTIVb9lHc7i9rwZrvWtBUfLmPGnh9MNLsqzaQKH/gDBn4Id8aIYKRh9hmozFTD8kTWchDMPK8ocJSHPYsD0XJ1UReofw2biGTyZgRGgntJKwVp8mjI0doIsALV1nIn2UhUI2xU3CuV7skPaTU+dKHwC1BD2kYdU+YVN9McJzGUt/it/Yw8YyOaiWrwiTB3vuoprzi8ky8XBDZqdSnW1fUh+dq/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=google.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=o8Y+KAlwvIgs/EoD6+wfqVoA2wqLIJcpFkJWsCwuWHQ=; b=tn8r/5U4ngzHyF/MW5kKcS4lTf0y9InTDOoxpOLg/3Q7B5wmlD+zAXu4Rz0WvpgNfphdkKplhq+A01dIdB69xZBYjzr2eDT1744ArOFa3oaurXVbgwXl7a4haQUTVcjCYh4wsK9IY8l5Bm/K43gptalistxmUOy9XgaWYnic0vE= Received: from DS7PR03CA0076.namprd03.prod.outlook.com (2603:10b6:5:3bb::21) by PH7PR12MB6587.namprd12.prod.outlook.com (2603:10b6:510:211::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.71.12; Fri, 29 May 2026 07:58:53 +0000 Received: from SN1PEPF0002BA4D.namprd03.prod.outlook.com (2603:10b6:5:3bb:cafe::87) by DS7PR03CA0076.outlook.office365.com (2603:10b6:5:3bb::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.71.13 via Frontend Transport; Fri, 29 May 2026 07:58:53 +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 SN1PEPF0002BA4D.mail.protection.outlook.com (10.167.242.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.5 via Frontend Transport; Fri, 29 May 2026 07:58:53 +0000 Received: from satlexmb07.amd.com (10.181.42.216) 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; Fri, 29 May 2026 02:58:52 -0500 Received: from [10.136.36.222] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Fri, 29 May 2026 02:58:47 -0500 Message-ID: <9dd1d24d-45d3-4ee2-8e67-8305b34bfb6d@amd.com> Date: Fri, 29 May 2026 13:28:45 +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 1/6] sched/proxy: Remove superfluous clear_task_blocked_in() To: John Stultz , Peter Zijlstra CC: Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , , Mike Galbraith References: <20260526111609.433880331@infradead.org> <20260526113322.120970670@infradead.org> Content-Language: en-US From: K Prateek Nayak In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4D:EE_|PH7PR12MB6587:EE_ X-MS-Office365-Filtering-Correlation-Id: 139757cb-8899-4243-bcf7-08debd58207e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|82310400026|36860700016|22082099003|18002099003|4143699003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: uz0umrDCIezqRpTaIBlE0AE1rFu7dn9Euw2al8UExYj74DT2+kRfGGK+0DAayrIfPkNDoPdq/6o1E8BEyjfzFEfZpA0lc7punWtbj6iMXqLzYGWi0Y2tpfI67lisJ30pp0iKPMYne/aUj02nf0eKuRxrj4/DdkLL3fIkX9rNZCyznKcAiaYG9Z4Cj8NSApwkzRwkoH0AXz4ZECBZqSOVT0skg1cjq0TK0aWEgRAMSuOqjGJ1l61OzstzGvzC8sdab2WN6mMmcp9acf/1fT/sRxfsvU4+yGo1qf0Nh5N52AL9E847I3LYIiyk22UOpMkffzhj2+olKOTLyNcB/XKRHtuBHfhNUf0sjWZ2CCFH5ITCB+wcd2Rshb2f65UgtfIWNxPTPA0FtHoYNt6VSsTuBCNMjjXFk1GVJaS3nO9/yL2c+/H83ROdQafcAbFAlX/7Br2ki2e7PiEtBRBWfiu5qSCz8lessg60c29Wm0DndU6cqB6Z1YZhc15t1CTp52/gvZizxWrg/wyxVOnwYlmRl+phQqE7NtPVUEn4GNgU3omqFO9oqDQTV+j7rfdGkAu+gCvjyoo1k3g9/Tk3xQxuzBb+OJ5jGlfhfjA6o6bgnrG7XrBU5GdiOXdhHd1i5BNhlp6szN5fcWBv4ZbzXp0kFMEonegZ0hAK91O8l9OkkQk/q6LbuHmCBFSSGdy73Q35ag6+6ckjX9D/Culrn2DhnsWKHl1gBngg2rgwOHpXJrA= 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)(1800799024)(376014)(7416014)(82310400026)(36860700016)(22082099003)(18002099003)(4143699003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 0uUAWefXP6I6hfp9ypZIJPmEWsmR9JbaRfyYNgN4V29U2OeGbAn14oSfumDq4NNal54tigsN0g9eN5OWN5D2Tulqkj297LiFI06s6U4Sk6f/aNyzffOG5NXTuH4+ta4Wtbqetfzt6PCMPY3PnuF/oJQ9ZdwF0IGCS8U+/lqos62OUxH2ZZ3DN//WYrXRK/4BN7Rz6juIBM4jTxHT6egu0YtlZ5itPBbog/pga7qMT0pFT1U8GoCRGbMDqW14mSVVvsYj5H5lUaVL5e6PANY2ODpFSRx3SgnZmJbAs7GU80//KN+uximGv6OZQK4t7gS3cv5wphyZPunI+jvpmf8M5hk7CyDE3rrxykzCdjGEv9jTZBbaTLbysbJRBJTXANYe+OJZeqkXfC+Hyb0jkG2auJd5+8Y/01UHOJjCDQanhYLKs1xi+y2ZlGYkhlrOdtWy X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2026 07:58:53.2526 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 139757cb-8899-4243-bcf7-08debd58207e 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: SN1PEPF0002BA4D.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6587 Hello John, On 5/29/2026 12:18 PM, John Stultz wrote: > Bascially we can get in a situation where (sorry this gets a bit convoluted): > > 1) On CPU1, __mutex_lock_common, we set task A > blocked_on/TASK_UNINTERRUPTABLE, and call into __schedule(). > > 2) On CPU2, task B who holds the mutex calls __mutex_unlock_slowpath() > and sets task A as PROXY_WAKING and starts to call into > wake_up_task(). > > 3) On CPU1, in __schedule() we pick_next_task(), which returns task A, > which is_blocked. We call find_proxy_task() and note task A is > PROXY_WAKING. Since its also current, we take the short-cut and clear > is_blocked and blocked_on and return task A to run. > > 4) On CPU2, try_to_wake_up() hits ttwu_runnable(), and > proxy_needs_return() returns false as A->blocked_on is zero. > > 5) On CPU 1, task A is running, it grabs the lock it was waiting for > and exits __mutex_lock_common. It then enters __mutex_lock_common to > grab a different mutex that is already locked. It sets itself > blocked_on/TASK_INTERRUPTABLE and calls into __schedule() > > 6) On CPU2, ttwu_runnable() continues, and calls ttwu_do_wakeup(), > which clears A->is_blocked and sets the A->__state TASK_RUNNING > > 7) On CPU3, task C that holds the mutex A is waiting on, calls > __mutex_unlock_slowpath, setting A as PROXY_WAKING and calls into > wake_up_task() > > 8) On CPU1, in __schedule() pick_next_task() again returns task A. But > is_blocked is now zero, so we just return task A, even though > blocked_on is PROXY_WAKING. > > 9) On CPU1, task A gets back to the __mutex_lock_common() loop, calls > set_task_blocked_on() and trips warnings as A->blocked_on is still > PROXY_WAKING. Oh geez! Me tries to visualize: CPU1 CPU2 CPU3 ==== ==== ==== __mutex_lock_common(MutexA) set_task_blocked_on(TaskA, MutexA) set_current_state(TASK_UNINTERRUPTABLE) __mutex_unlock_slowpath(MutexA) ... set_task_blocked_on_waking(TaskA) schedule_preempt_disabled() wake_up_process(TaskA) __schedule() /* (1) */ ... /* (2) */ if (prev_state &..) TaskA->is_blocked = 0; next = TaskA find_proxy_task(TaskA) /* TaskA-> blocked_on == TASK_WAKING */ clear_task_blocked_on(TaskA, NULL); TaskA->is_blocked = 0; ... next = TaskA /* (3) */ rq_unlock(CPU1) try_to_wake_up(TaskA) rq_lock(CPU1) ttwu_runnable() /* TaskA->blocked_on == 0 (4) */ ... set_curent_state(TASK_RUNNING) ... mutex_lock(MutexB) __mutex_lock_common(MutexB) ... set_task_blocked_on(TaskA, MutexB) set_current_state(TASK_UNINTERRUPTABLE) schedule_preempt_disabled() __schedule() /* (5) */ ... __mutex_unlock_slowpath(MutexB) ttwu_do_wakeup(TaskA) /* (6) */ set_task_blocked_on_waking(TaskA) /* (7) */ rq_unlock(CPU1) rq_lock(CPU1) /* TaskA->__state == TASK_RUNNING */ next = TasKA; if (TaskA->is_blocked /* False */ && TaskA->blocked_on /* PROXY_WAKING */) /* Skip */ next = TaskA; /* (8) */ set_task_blocked_on(p, MutexB) !!! p->blocked_on != MutexB !!! Yup! That is a concern too then! I think we can just squash the PROXY_WAKING removal with "p->is_blocked" introduction and a part of this problem should go away since unlocks always clear task->blocked_on then. > > The chunk you drop in this patch effectively clears blocked_on in > whenever we notice current is TASK_RUNNING, which keeps us in sync to > avoid this. > > I'm also wondering if dropping the shortcut returns in > find_proxy_task() that clear blocked_on and is_blocked is maybe the > right thing? Just to reduce the cases we have to wrangle here. > Even so, at least in my initial testing in doing so with just this > patch that doesn't seem sufficient as it seems ttwu() can still race > setting A->__state TASK_RUNNING vs find_proxy_task() hitting a > proxy_deactive() case tripping the TASK_RUNNING warn-on. Yeah, I tripped on those bits in the parallel thread. You can perhaps give those changes a try. > > Maybe we just need to move the removal of this chunk till after we > drop PROXY_WAKING? That would be safer, yes. -- Thanks and Regards, Prateek