From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazon11011029.outbound.protection.outlook.com [40.93.194.29]) (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 545E43A9018 for ; Fri, 29 May 2026 10:54:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.194.29 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780052064; cv=fail; b=eQZTtYe1fTWnOZPXQIvs+VoHzvf5WBVYE3FIqptN8olXbvi/XvwQL4hPk1YjIRo95MKFP83g/HycYj5odpYM1ZI8JY7mBlSIwUcLLXxm5683zhVzP1XCj346RJ6dt5V0G5IfJ40SUc/NuQnMP6Bp1Kzo9MrN5ghLIBe9rjHtPUY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780052064; c=relaxed/simple; bh=1FGyHyf9jNXwZ6g4Lupf5GGb6gkBk34pQb4qWu/sa/8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=RhGQ08QsVWS8jtZvd2IMnu7gvi6ktqMLbWDe+mHcD6/+WPwGOGgRAGoUfpBOYd+wTg+/WLftXlVeCkLdjAlhsK+zhFU1hdhIS8UBbsPNPCh4+UGzwU4oFVmpouEaFRzQ5IOq0zabpe1jHG4qVfvkk90PbGBjg+X6LEFmbXM/MeA= 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=Ke2y8ZHp; arc=fail smtp.client-ip=40.93.194.29 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="Ke2y8ZHp" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xWvH0WmweXO8KlrKUM3ggq/Hr1LS15N15pvnp47bch7XIwIWt945xZX2rja3m+dIR2CZhR1s4YCgFItwIZ8N4wDxsCTqzdPYuQd5493s1F9GN+lVDZfP5EaPb7yL7q0ABIt27ndW6YUhJQiJpOB+js5PqYMJkFtM3sCiypiSouKkdHu48Eitl1KWSfPQFZCK7/Rcadt78bhFHJ0vQr6ROOpDQa6vT4mpU0sfuZXrrorKLm1EzxCQZEzj0qj4xqkzW4IQmcI0eA07WVW1lxnR9g23VASGz8y5KGMLfAQNGILrCMVgn6cceRWIoJVxNspXl8uMMS5PjEzaUuvyx6MwOg== 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=fi3irp0g4pxnhH/gM5WiqMpp45rcTN45HELrZWKDpvI=; b=Ep67mIkzSoEi+hHNgvEoCmfoxAAyWMP7aIxGJmSWrJPBa85Oq9Qkl+RyfA5+BpZNZDAavz8q1jlfWOM5ZHl2w+lkgg2OsDbEtWGEQOht1kMi4qyuPwsYjr762Qf7gCZ2/BVbIxeXCerwljTIKWgXkOfJRd1ftdZk2dvSGNFugV/HrKW4036R2r0+KdcX/48iRZcJNnFbdrUWTEnUWiQcVoMgNfXJRjz7MgHJJu9x0By0GF7Jp5i5gm7z6d7FwF3izHTCDBV1mEhnNs9E/Djzoby4+KGAfKUl72Eygsbza5UMQsV8miMAatfTMSTYv/0Misy1JvKzK28+l/hiJ1BB/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=infradead.org 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=fi3irp0g4pxnhH/gM5WiqMpp45rcTN45HELrZWKDpvI=; b=Ke2y8ZHpC917engW6DEjdWBP1Bm6vuMo9dWQ2IIbFyaBlUD96tsBDE0TcqlEnul++kOb+uWBD6/7v6sMf4c8Du0B8bbqDLybLb/ZF44UW7CuveGSXFoTjbcBKikLGCbBoyx25WBDEIeFi/BzOkCv6FVYm+9JCGI4FLYdGYffAnY= Received: from MN0P220CA0008.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:52e::7) by MW6PR12MB8913.namprd12.prod.outlook.com (2603:10b6:303:247::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.71.14; Fri, 29 May 2026 10:54:16 +0000 Received: from BL6PEPF00022572.namprd02.prod.outlook.com (2603:10b6:208:52e:cafe::8) by MN0P220CA0008.outlook.office365.com (2603:10b6:208:52e::7) 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 10:54:15 +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 BL6PEPF00022572.mail.protection.outlook.com (10.167.249.40) 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 10:54:15 +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 05:54:15 -0500 Received: from [172.31.184.125] (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 05:54:07 -0500 Message-ID: Date: Fri, 29 May 2026 16:24:06 +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: Peter Zijlstra CC: John Stultz , 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> <9dd1d24d-45d3-4ee2-8e67-8305b34bfb6d@amd.com> <20260529100649.GB3144646@noisy.programming.kicks-ass.net> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260529100649.GB3144646@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF00022572:EE_|MW6PR12MB8913:EE_ X-MS-Office365-Filtering-Correlation-Id: 5c062ef0-4e2c-4cbe-e2d9-08debd70a056 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|82310400026|36860700016|56012099006|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: /cDIe+SQVA2fKTRPDvgDw+XUD7IeoNAV8zydd8ezB+8OsyqT4V3PIE8onvxaaIvaB0LMoxGKTowmjlZ78iMHIcw0qpFm6xpRNGgM/yhklMOiT0AjNjDB5DmYK0zEyHftzwKvtDxAGZ+u58oHjrHEYvfQE7DrkxnzRvFE2iKjRdk2TBKYXl422Lpf5acJ7AxGtX3NCEPEl0WF6xrnWTB09o4m/Z2n+q7sSFUnLkM1oeK8lU8Kvx6J3//MYAvAIumGHxCGHP2w3tKZo7kwNHOpOyR/Y2D3Ajhe3GdJhX97qoLIi93t3/1FLD1GRwW5NxCB6pLOu9Pe0BKta9sC2xR+kDUjMHSAAi2sB4J/GPRoj9Tebpyi6je5GYici7lVAvIoYsgf9OOE2xZOL6bQIxy/jsMJfpH1Xk/A22n68PDGa6qTwnRiRKJpsRQHlw4K3s4Md5zwn9bd+y/3t1Q3LtQeSag2hDR9ao+Cp8eHZptJYegCrdKl7AvWqSD6tvEupJQ1g+OgXR0numiuCUbyeZzWnaHWYpYxCWt7Y1FT4VqwHQ/oZ/vZInWlBdKfvc2TebpAgVnq3uxAucvuMMt1E6ijLe3sH3CTflewmGv8m4ka6ThgMxK3PzbFr3URVEPLXVVFwLZiRBD0qqKJ61R7r8vNhBIbw1o7gGLhLWcLBhTohLNnAKRISHWaQ75y+y56WQxr4QD6yZo8s6Ns8hu84D2KhNDa5hwiUiJ4z6JoERiKc14= 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)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: XaAf+uixLMu4o6Q5+H1yXw9jy9VeFQK1EBGCKqg0UTdMyN8UO4N+ydIyPFx6Hb/F6tsJtJetFuZ2N8l3ipquoBjv/DLIKckbPwIuqa828AxU4U2wztsjEwcM1ACT236aYPlLmhobx6Ab4bEHaFNDMSXcMdqmO/RY4rl0d7Bov4Ii21dS1WmVHs7Cs9a/0421itqtnLN2Vl/JuLf8Gk+JGwgLGZ+phXCpkDHDOBNYP86Ontl2honBpKd0uJHhpoN1zXkGyr5+QrjjtOfX6Vi7ZLWqhoIQw/35Jglp07Bjv1MW33aMA3EHrdd7oJAEBelNLFcNgBsZUSpJV4IhKQkDVf6BSuMnyH3v6kBWuAVeMTRTgViW6QPgJXYq1K7m+eDGHady2wmzAcjtl/bIce5Y1eguOueMZ+XljxaefIwqNpYx5ovGRDl8dqW92OPfJ0n4 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2026 10:54:15.6954 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5c062ef0-4e2c-4cbe-e2d9-08debd70a056 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: BL6PEPF00022572.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8913 On 5/29/2026 3:36 PM, Peter Zijlstra wrote: > On Fri, May 29, 2026 at 01:28:45PM +0530, K Prateek Nayak wrote: >> 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: > > Thanks!, I too need pictures, prose will forever confuse me :/ > >> >> 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; > > Should this be: TaskA->is_blocked = 1? Otherwise I'm not following. Yup! My bad. > >> 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. > > While staring at this, I noted that the PROXY_WAKING removal patch > should also remove the clear_task_blocked_on() line in the very last > hunk. > > That said, I do have a note to double check the lockless access to > p->blocked_on there. Now that PROXY_WAKING is gone, the only reason we locklessly inspect p->blocked_on is with the intention of clearing it. If we see a valid p->blocked_on, we take the lock and inspect it again. If it is cleared, no other entity except the task can set it for itself so it will remain blocked until the time task is selected to run on CPU and the blocked donors don't run until they are woken up. > > Anyway, yes, the hunk removed in patch 1 cures this by clearing > TaskA->blocked_on (because prev == current == TaskA). I don't think we > need to squash everything into one giant patch over this if we just > reorder things. > > The Changelog of patch 1 needs an extra few links to this discussion, > but that should be it, no? Sure! That should do just fine. -- Thanks and Regards, Prateek