From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazon11011011.outbound.protection.outlook.com [40.93.194.11]) (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 4BBD3346ADA for ; Fri, 1 May 2026 05:57:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.194.11 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777615065; cv=fail; b=UVBIKnvtX2BYGcH2NA5TK7R9D0NgWTegTGJCCd9RB7jJr53fOnbbn5DTIm1z4q2Y4uVh1RNHsnA/fl4Y2NmaF4T5NXXeKoF7SIB3L0x5UTs7upHQTaR+OA4gJNzZM1AEazbyAaSe3qTRwDR114EFdV25KHWIt+KishMFX8aIdSc= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777615065; c=relaxed/simple; bh=202TPF2pm+DMD/6W9wP5rmWFmo1jyuUqHhb4lJgbfHo=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=SfHPdjhTapDIN1/vpiHDis1jq00cA3xYsOQrRzv9u7IpUHmYX7Y0VPhgz2YnMnGFXgbOT4alSizu3FeooKX5lg4hUzjiRdK/dXc20JQbvMygcQ1NRsL6kC5yzIi02iuK/XGKp8996ix4NQ4NPdBH3jqOhUu3IERsFTe8AvstC+Y= 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=H2P7Ssex; arc=fail smtp.client-ip=40.93.194.11 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="H2P7Ssex" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IiwO9mYPZSlvpZHSe/TGnooZrNwjTyM7/yLqlwfnCNby2bwt1JPU90NVO97byvxCosms1AlZt6QELlVa2C13TRopr+0RfYotf9bmKa3Zph9BAmbpIv+i+OU2QL9ujqv704Z2WYYN+iFwJ/W3MsjqTzJizC1Lx2+0/U2C1u6HQGsFwEKFDnpxC8A63Mg77uw0zEPb9JKtUfUFOzTkcQGSrrjpblAXuBlK/5YehpW6OwpUZMoRU8rldnTAA7VBu5iskeyTnX0QapWkJlH5Iy7J86C2nKk6rnd+KoTIWlUrPcdHvh4LxFnWFaG5GD5w61ww08MgCLT0G7faESuD2E2jHQ== 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=n/P1pfCK0GSleh73h2DxVbC+PoKhJf/4U+utiLSaUqk=; b=U62JmcmsjX76O3r73B9+Ocsw8xpDCsv5YLCY5Z1Qm10KtPHvGDVAv3J4WIDt9xj4qvOgunilmoX7tNRICw+6mWt+ZBA4Zy6w7wpPrrC6WgvkHxlJT9TZhpYS3A83gUE11PBKgqBvCS44indUepKZ7IUEGyOD0RxSff7EkWTPXSqq7LrsHDevH7poR5I5PVDu7ZEimUb/awAjECCFNJpoiUtBvLPB4R4hvXm4SypNtkYFmo2n4RvfJ7c6Z0xR6R/IAutzl2r+H+RdM0tIbxPFl4JAGlVKQoI8wI+jIFiy2GDJxdp/ddl58tL2l38H0AGzBJ/KmXtRHSElWRJt2TgVZQ== 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=n/P1pfCK0GSleh73h2DxVbC+PoKhJf/4U+utiLSaUqk=; b=H2P7SsexO61YKvXmPfAgl8Nxnfw7PhOtMHb/Mnk0Epz1vQPdRbRf2R+tNN0wqKauSD1i5uC+IInf0TWzUh2XPknGQ96OXSysxjFm4Y9McuZ4xa8G34o5C0b3f0SB2dDr3KIhRVdxmApxz0smFHiPs4VUb6Mm+tLdQybYLvM+9x0= Received: from BN0PR02CA0019.namprd02.prod.outlook.com (2603:10b6:408:e4::24) by BY5PR12MB4065.namprd12.prod.outlook.com (2603:10b6:a03:202::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9870.19; Fri, 1 May 2026 05:57:37 +0000 Received: from BN2PEPF000055DD.namprd21.prod.outlook.com (2603:10b6:408:e4:cafe::44) by BN0PR02CA0019.outlook.office365.com (2603:10b6:408:e4::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9870.21 via Frontend Transport; Fri, 1 May 2026 05:57:36 +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 BN2PEPF000055DD.mail.protection.outlook.com (10.167.245.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9891.0 via Frontend Transport; Fri, 1 May 2026 05:57:36 +0000 Received: from satlexmb10.amd.com (10.181.42.219) 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.17; Fri, 1 May 2026 00:57:36 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 1 May 2026 00:57:36 -0500 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.17 via Frontend Transport; Fri, 1 May 2026 00:57:27 -0500 Message-ID: <9f39560d-c4f5-407a-9afe-48a78ad69159@amd.com> Date: Fri, 1 May 2026 11:27:21 +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/2] sched: proxy-exec: Close race causing workqueue work being delayed To: John Stultz , Peter Zijlstra CC: LKML , Vineeth Pillai , Sonam Sanju , "Sean Christopherson" , Kunwu Chan , "Tejun Heo" , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , "Suleiman Souhlal" , kuyo chang , hupu , References: <20260427183848.698551-1-jstultz@google.com> <20260427183848.698551-2-jstultz@google.com> <20260428094353.GB1026330@noisy.programming.kicks-ass.net> <20260428111833.GL3102924@noisy.programming.kicks-ass.net> 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: BN2PEPF000055DD:EE_|BY5PR12MB4065:EE_ X-MS-Office365-Filtering-Correlation-Id: 1188d313-0419-49c5-d7ec-08dea7468bb1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|7416014|376014|1800799024|82310400026|18002099003|22082099003|56012099003|7136999003; X-Microsoft-Antispam-Message-Info: V+S+rRC8tpV7n5K0rjpkpZGeI402/iYAoY4QOri3HzqVZzRhnGjFgEhxzAExUkPuVvAApuiUyndBBC8Liy0lsmUGpp+6LteniWRSjnk54r7s/miXqtztwElYrWtl4MpKh3C/sf3PhmL12nN+6NDUfXs0F1+OalDreSopG21LvlK4Dkq3jDELgtbeq371XaJfkHJn0eMGL3XitRtgsD58RJpbwVH2laIMDGauD76q4EMlGcQYeb7BFvtUoRibEmj6PbQfdMeyzBFsy3L1ajBdZt+HnSiJD/aF+lk1ocvkOWxa+HvN3pgbFBq+xpux2UhYVZePWJ85b0Y6AObfDAr7qhjEgvH8NXBVYreZZHWMYJJ73PdD8/d62AbgF/HvnJ390GndNLLybnoJuRxXv01TUdWw616YHPcToSrLFUbLnxc0+AHH2/ZdPMVoEqKynPDvuEJwtu6a86HJFqBO7hD880ArU1AHBpi5Ozc1hB9eil7FVVy1qG+i3MGjldYv3u/M+m8cKkWdNwuXFz6l0Zjg8D6vQxINu/bGLgWFwv6t874BvtI8bUgzWdCe3b95U3Lq9Yls4ADPgvtEFmsttHZ3YiYS1SFQRjyOZrEs9ruOqZ/O1XbOJQDOLGweu/YP1D+cL/X82/gaJUPYHhnyccQIkVHIaOOlHgfcCWS5tpViqqTX8X/cD3NlWztUUDBut+rRh3CpVnwdvllF0U7yWn9j93gmXTi7UAOjKuQM1M4P/00= 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)(7416014)(376014)(1800799024)(82310400026)(18002099003)(22082099003)(56012099003)(7136999003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: hr46XjODwTNbtl9DpaO90y3tfJRrzkAGKh5EKNeOxn6KIW5Kq8pVgD22e+4EoHiBzSzwRkjSv9id9iX4Zzx9QyhDprTVx4bRYrRVF9VZ3aA+h7oeitJTH+jAREe8XPvgX+S+ud3jHo/yFpKtImzxsBZ7jZIKEMxpBG3InBLKwACwxNzaYSvo7IfNZUGVd+YHcKq+zGFERInxoZSKugRwIRcJ0LLgCaBGkc8RksmIP0MlAZ0CTJ8DCCQ4v6DJvFCtwzYeIzjpe3xSw2Q9T3nrPnrMljo5R7RG3iV91k2y3j7zrioamqu67JrBoyQ8JpTIy9ha0iclJ752f7cwSQxKeX1+WBNS3DwBN3ZoXsyhpdHXjOhgIOC37BAgL1syepMzRheYNJsp7vR1P11o+uB38tF9ASZ6KDCkSifjBU2K6j5l/HWkLvRMaicGRutCJFv8 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2026 05:57:36.5996 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1188d313-0419-49c5-d7ec-08dea7468bb1 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: BN2PEPF000055DD.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4065 Hello John, On 5/1/2026 2:10 AM, John Stultz wrote: >> Any wait for non-special states that is not a loop is fundamentally >> broken, since many of the lock wake-up paths are explicitly racy in that >> they can cause spurious wakeups (which is the safe side of the race, >> since insufficient wakeups is bad etc.). >> >> OTOH special states, are special, esp. because they cannot handle >> spurious wakeups. >> >> Eg, consider something like: >> >> set_current_state(TASK_FROZEN) >> >> current->__state = TASK_RUNNING >> > schedule(); >> >> is all sorts of broken. Now, obiously special states must never have >> blocked_on set, so this can be fudged about. But still, touching __state >> from schedule seems wrong. > > Hey Peter, > Thanks again for the background here and the alternative proposal > that K Prateek and I have iterated on. > > I did want to clarify one case here just for my understanding. The > approach in this first proposal was sort of leaning on the similar > pattern in the signal_pending_state() case in try_to_block_task(). Is > that just a hard exception to the rule here? signal_pending_state() looks at the task_state only at a SM_NONE / SM_RTLOCK_WAIT preemption point before making a call and only sets to TASK_RUNNING if the state is (TASK_INTERRUPTIBLE | TASK_WAKEKILL) and there is a signal pending. All the wakeups for that are routed through Everything outside that state and coming from a SM_PREEMPT path will leave the task state untouched in __schedule() until it hits the natural SM_NONE / SM_RTLOCK_WAIT preemption point. Only looking at ->blocked_on, and not the prev_state to set prev to TASK_RUNNING can be dangerous. That said, it would be stupid for a task to sets a special state and decide to grab a mutex which overrides the state. With the latch design, we are more or less aligned with something similar to signal_pending_state() that looks at the tasks state from a safe preemption point. -- Thanks and Regards, Prateek