From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazon11013063.outbound.protection.outlook.com [40.93.196.63]) (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 213C720E334 for ; Fri, 10 Jul 2026 04:04:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.196.63 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783656259; cv=fail; b=QfeGBeImhYb1P0ZIpARUP5H+jFikgesDgHzKsGHA/ZkPVx9PkUG1X18XR+mFnXxNtud7eeaaKkVxYtkf9VUErCuORJVJEW5WhYlM77LKPTOjUdOeNVEKpkh3SQaRNvL5EIfQHs/Tlq2zFlwV2M6BItmS57hGsCE0x66ifW/zjbE= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783656259; c=relaxed/simple; bh=8Jg2sEnVxV+HLeRgGO8uBlft88FWBtHHUAr2KiyFRjY=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=YA/s1q+A9EcKnFOmLE6ZquRi1uYegZyLTwIza6qSor1MJpJoldm6dp/UM9basZPWZI6SNnV3lR4W9HNXgEOlP91+M/MvJvckZzq0m1ozmyo5iOfGjUAJoLCaC/Jquh/o2yRu7M6Hv4i9EqVe1vm5UjPSvaEfsY+qymXzJVRRmSk= 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=wOAuUhIT; arc=fail smtp.client-ip=40.93.196.63 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="wOAuUhIT" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HqpffAEyVv1gV0Vz7XBaaeB3zULHp9IgmLelntB4AiWVm4TKNsZzro6Bt/gGtIpGfwHh1ES2Ev2EMQIpGkOK/TjD9G6/mRj34q/eu2k612GvtcokbbfdT4wpfY6XmqEwSAecooqBFZKPUOQGPMpiUF7y/g9BvCSFef9vjGOlf0IkB7O0RWp4AcViLw1HoFvEqgLHfHARcOwM29aBuYnc3ixUAv7aFyPs1rgI/KIx4F+0gv0xg1/3ykuFdYj2V76UP82CVNCmZ6O+fkoNHmGR5oXmqohKLOPbvfvHowDKeEkWVLQDg1YSDqN6hTwevt2iF7q8mPE67tN/Rc5LuyHeWA== 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=DD9g3uXN9r6ex11Fv1Prbit0m0ZBqXTByTKZdiK9UZk=; b=Ef2m+p3UvuMOExHU6/UMirs9arIiDJxpeT/HGthXjvRqGkMAwrMZUoihaebxVIKo2A8o3UKqjWI2jrOziJik475wQv5uSJ4m8viAVJbiOmRqvJW80iX0qleE93meTklpacpyKe1TDf3EBi6L5gicsQvwWa9tmG7pj07FtFpUlDgJPoM4frqdBI/CFNj4TreYcsoNRPJTpMRDzgC4FCcURz3zC9q1m4PaRunGjpjObWHFiIAb7Y0G/GFLUluwkwtPmL1fH4a2gOV4v56Ci5212dy7QAiH8B7nH+lALiCmjm/bGklt0GUQ0raJWlTFkL9LVD6rl1miJ0YpyRuLCsLmVQ== 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=DD9g3uXN9r6ex11Fv1Prbit0m0ZBqXTByTKZdiK9UZk=; b=wOAuUhITAtX5CZuHV2BAYt4f3KTAe/4JZ4J0Ea4P5Duvw/gq+dKXOTlzWLS3kdPi2ECJFNxOdFZuhyGM/76idLLsGNx45EAbIFmEuzBn1fnRouVZYDn4GrHThZzpxcpj+CCGIRsoDaPP28xisWwoKvGO+UfzlJiLSNRtjdxhDrs= Received: from SJ0PR13CA0178.namprd13.prod.outlook.com (2603:10b6:a03:2c7::33) by DS0PR12MB7560.namprd12.prod.outlook.com (2603:10b6:8:133::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.17; Fri, 10 Jul 2026 04:04:11 +0000 Received: from SJ5PEPF000001EE.namprd05.prod.outlook.com (2603:10b6:a03:2c7:cafe::86) by SJ0PR13CA0178.outlook.office365.com (2603:10b6:a03:2c7::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.223.3 via Frontend Transport; Fri, 10 Jul 2026 04:04:11 +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 SJ5PEPF000001EE.mail.protection.outlook.com (10.167.242.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.6 via Frontend Transport; Fri, 10 Jul 2026 04:04:11 +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; Thu, 9 Jul 2026 23:04:03 -0500 Received: from [10.136.35.241] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Thu, 9 Jul 2026 23:03:54 -0500 Message-ID: <7f7d3d51-3920-42f9-bfed-40cf4a33119f@amd.com> Date: Fri, 10 Jul 2026 09:33:47 +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 v30 7/7] sched: Add deactivated (sleeping) owner handling to find_proxy_task() To: John Stultz CC: LKML , Peter Zijlstra , Juri Lelli , Valentin Schneider , Connor O'Brien , Joel Fernandes , Qais Yousef , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , Vasily Gorbik , References: <20260701214615.3773339-1-jstultz@google.com> <20260701214615.3773339-8-jstultz@google.com> <2d96999e-961b-4a10-b4ea-a8480baea2a3@amd.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001EE:EE_|DS0PR12MB7560:EE_ X-MS-Office365-Filtering-Correlation-Id: 2dff150b-5fbb-4320-3281-08dede384c77 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|82310400026|376014|7416014|23010399003|30052699003|18002099003|22082099003|56012099006|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: zUoXoF4MpRDWIsEn1O9pvnQguMVNWbrtusSD2LqCxmiHdmV5YucjP3GICL5KjB0LhJSCHFdbWzaLESBI0z7hU6gpKaaAkWLxiFTeOZgNl1n+YVuZ53xeU3b1BugOY62r7mcFh1oP4za9krv3lqzjSvu4HtGjIhfGSD03lgD5tVubDHmv/Gh3XAyEVGoUDClSGKUWTKplqKg7xbtkcRFnCF9XzU64VUKMfRBajNjSEjHn0txBYPQ8lx88G9L1elNgLwo96B8QwlP/RgGO8OFcHiJmDOPXHroG3FwD7REm+mzdSHumwDQM8qXe5myrFCAqMGhKHIBYZww7CGXuYeDQlW/Y0T79j2hWFuljQrLq+5Iawnk892UssIcD4vTytmbMia9VZWWWXE/gABYLWFNTV7V1wBzYqM3yQzL4GMkSyKPQFIMJeRlcGqzQwKPAThKts+ys/aKxxexRng4enUmesYukV7SHZpfpKwWHxxKy+wb9CkpjQ4/UC43X0CEI6TSsu7ROGLnr4Tu0Xu1rjawHaJJEg8Ti2GwdpW7Bk+agqh+QDVOHIBM8TjJOOqcEwMUCpXIG7K2z64s5Iip+13PzZdMw49j2h2X1zAY/5clcDskzWR8mzSRMXMdqyrlN+KpREBmVbYjUi8w5h6h5wceF+1t+ciMXKqY/8JRYHZDjCHmvJUcxJaFh9VS4m6Quywl1ZY/xhDVpzPbK6Q1RbUS2gQ== 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)(36860700016)(1800799024)(82310400026)(376014)(7416014)(23010399003)(30052699003)(18002099003)(22082099003)(56012099006)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: slFH9dFhsBBHusSXqFMZgzYoRP+Tu19eebO5mFiKErm1tNGdKzOEKg9RLcgNp6pjI9OOdPwvJTa7HVgf7MIIMrPCtQ0VI8F1rCgPR/WDSCtRhcaLiNKm10jbtBBGW0oWYca7chPFxso3orXqS3BZME7vhxb4x1swm8esctpR8uybNGeUM6dqMuKjMZJ02CevPyolIMrBFLccpuTWh7sfN0b/TUSaD+1ko7TtwLwH3JIkBIo0ylzhB7X6DnZSv3oMdLhMXi3pijylxJjpayr7+Mbyhqkmw+X2V5IJVKyLNe7P44PD20uohihCN2v5SfFxoeSlZ5gY82SQyk+xrDmx6QI2+rOtEAD0qWUCSqV0jp7AsgymGeFXwkEZmzStu/dtwMHQTa8jaMAU9nFkqveblA22RLN2k2KBZnmBPCOyQ8gafnCTx59NbVAcwbAv+3N/ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2026 04:04:11.4263 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2dff150b-5fbb-4320-3281-08dede384c77 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: SJ5PEPF000001EE.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7560 Hello John, On 7/8/2026 10:04 AM, John Stultz wrote: > On Thu, Jul 2, 2026 at 8:07 PM K Prateek Nayak wrote: >> On 7/2/2026 3:16 AM, John Stultz wrote: >>> @@ -6852,6 +7073,28 @@ static void proxy_migrate_task(struct rq *rq, struct rq_flags *rf, >>> proxy_reacquire_rq_lock(rq, rf); >>> } >>> >>> +static void proxy_enqueue_on_owner(struct rq *rq, struct task_struct *owner, >>> + struct task_struct *p) >>> +{ >>> + lockdep_assert_rq_held(rq); >>> + lockdep_assert_held(&owner->blocked_lock); >>> + /* >>> + * ttwu_activate() will pick them up and place them on whatever rq >>> + * @owner will run next. >>> + */ >>> + WARN_ON(p == owner); >>> + WARN_ON(!p->on_rq); >>> + WARN_ON(p->sleeping_owner); >>> + get_task_struct(owner); >>> + WRITE_ONCE(p->sleeping_owner, owner); >>> + /* >>> + * ttwu_do_activate must not have a chance to activate p >>> + * elsewhere before it's fully extricated from its old rq. >>> + */ >>> + list_add(&p->blocked_node, &owner->blocked_head); >> >> I'll refer to this list_add() as (1) below ... >> >>> + block_task(rq, p, READ_ONCE(p->__state)); >>> +} >>> + >>> /* >>> * Find runnable lock owner to proxy for mutex blocked donor >>> * >>> @@ -6938,11 +7181,31 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) >>> } >>> >>> if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) { >> >> I'm having a sneaky feeling that, with enough bad luck, we >> can go from seeing !owner->on_rq and here to actually finish >> enqueuing the owner by the time we get to (1) ... >> >>> - /* XXX Don't handle blocked owners/delayed dequeue yet */ >>> + /* >>> + * rq->curr must not be added to the blocked_head list or else >>> + * ttwu_do_activate could enqueue it elsewhere before it switches >>> + * out here. The approach to avoid this is the same as in the >>> + * migrate_task case. >>> + */ >>> if (curr_in_chain) >>> return proxy_resched_idle(rq); >>> - __clear_task_blocked_on(p, NULL); >>> - goto deactivate; >>> + /* >>> + * If !@owner->on_rq, holding @rq->lock will not pin the task, >>> + * so we cannot drop @mutex->wait_lock until we're sure its a blocked >>> + * task on this rq. >>> + * >>> + * We use @owner->blocked_lock to serialize against ttwu_activate(). >>> + * Either we see its new owner->on_rq or it will see our list_add(). >>> + */ >>> + WARN_ON(owner == p); >>> + raw_spin_unlock(&p->blocked_lock); >>> + raw_spin_lock(&owner->blocked_lock); >> >> ... by the time we get here, activate_blocked_waiters() could have >> already bailed out for: >> >> !list_empty(&owner->blocked_activation_node) >> >> and then we go and add the task to list. I feel, like most conditionally >> adding to list patterns, we should add the task to list, check the >> condition once again under owner->blocked_lock, and then proceed. >> >> That way we can sure the activate will definitely see the queued task. >> Sorry in advance in case I've been blind and missed something >> obvious :-) > > Hrm. That's a good point! > > Let me take a stab at fixing that. I'm thinking it might be easier to > check on_rq again after we take the blocked lock before calling > proxy_enqueue_on_owner(), because otherwise unwinding that is a little > complicated (pulling it off the list isn't, but the task will have > been blocked, which isn't what we want if we are going to pick again > to figure out if we can proxy or have to migrate the waiter). Am I > still missing a race with that approach (instead of adding to the list > before the check)? I think it is safe since the unlock on owner->blocked_on will act as a release barrier ordering owner->on_rq = TASK_ON_RQ_QUEUED when the owner wakes up and the grabbing the owner->blocked_lock in find_proxy_task() adds acquire semantic before the onwer->on_rq load. Only downside is you'll need to check list_empty() within the blocked_lock lock critical section. > >> On a separate note, is it worth tracking if the task is a mutex / lock >> owner and only go through the activate_blocked_waiters() path only when >> a __mutex_owner() somewhere can return the task being activated? Perhaps >> a per-task counter that increments at every mutex_lock() and decrements >> at a mutex_unlock()? > > This as an optimization to avoid taking the owner->blocked_lock and > the list checking? Ack! I had some more interesting (read stupid) ideas on top with that but I'll try to see if it survives a boot before bombarding you with them :-) > Let me think on that a bit. > For normal mutexes it seems easy enough but I want to make sure it > doesn't get complicated with ww_mutexes or the later proxy-rwsem > support from the full series. So, with rwsem, I recently realized there is {down,up}_read_non_owner() which is interesting, but I don't think we set a p->blocked_on for those cases and since the "owner" is always NULL, I doubt the limit usage of it in the kernel even cares for priority inheritance. Apart from that case, I don't think there is any other extra creative locking patterns possible that don't have symmetry for lock and unlock. > > thanks > -john -- Thanks and Regards, Prateek