From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2493C346ADA for ; Tue, 21 Apr 2026 12:08:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776773316; cv=none; b=UbrRzkzwQgtwHbbLh3mEPkIdhyQ3H02IjGkgTRVDb0K3SBsGyBJUwXf54pRXDiqIvOx3VzBiA0aHJiGkvl/e7kSHjh6umhDdrVoa0jhFUKIhNqbRbjHtG6eEgHouzj3e+tf1QnJP5lC/HhXQWPcYeCBoePJUgNGJsDAPTo8uifI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776773316; c=relaxed/simple; bh=30hwgQqD5VesHFl3vLw5u+tNgHdFbw+t30ya8OjBOXs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CFgGI4+BJouwXLTgzh8CHvbvCA4ek7fskdLUUhXggO3iLaYV3c3cOFPG8mKi+hhVcrsWFNyjyoPMcbpQ14NE658TdiMNqQMqjFdVzL5wC3frli4uzdqFmmaZfkE9gA4eQA6qyJ2v6iiDaT6jJvJQnDKNhDVHU8Er/RQYUX3heus= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=UbC+KtAE; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UbC+KtAE" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-c76b994f7a8so1438526a12.3 for ; Tue, 21 Apr 2026 05:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776773314; x=1777378114; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7UzKS2TalSVQ/4qQr4b5ctTsLmnBUwNup42PXvc2L6w=; b=UbC+KtAEvrNWSVDbxYcniFJ7T7QqWk1CA4n7oxXylnTSf54nHptbXiT0Ehnp72kbV5 QH6qWx36i+l80r2INJfNFszNYQrT8ob/EqbGyUqeOd7zIER9TJpDD4cshSxO58x5u+68 HzSz8kt4IMVIYf2YIEQhYqGfEfnrdXjInT1AQ1Obj4ozRwaG/jNrS1sI4x7jSL1Np2JA QRdWoroUHUSB3HBvolq5n+uXajWVHw5O4GJ1BeThF3l0fI1tAJ1CnvpBATl4iaXI4jOJ vm3obGdW/PuOOqWhoGSWBldROEXbfg1Lot+LpMCCHbrQD3fwnmPnmQKy6TLJ0hlfKQv/ Clbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776773314; x=1777378114; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7UzKS2TalSVQ/4qQr4b5ctTsLmnBUwNup42PXvc2L6w=; b=ImCp4c5v8MAXIjDe93aN6aMBzF834zcaUvmC2kOv+DDwv9OIvrppYA7AKKDLoFGqnw DMURUwrL6csQosnsz6nkL0Y2rxw8WY3c3BgecDVMNbCu/LzaADraqUOMJsjw4jacLj6T heWhRrrrzN+g8BWFSqqh/rhq6oqP1gOjXmg/cyFOqvPKjKT61uYzlaDiV1GvKEVEaNzB gYfP6UI+zGiCPm91+m26mf+0NIFO2/mwEZ3esiYQ4KFx09HPKt5iCL+l59migXOJKSvE l7MA6oYQ087n/4qqz25qsF7MqHJ//J4u99QO7UB/zCE2ult+a1QGUsRqaX92qw5r9Xyz nVhw== X-Gm-Message-State: AOJu0YxERSaXKeMvqM/dVt/I2SC3QgIxySdU3s6APJsGW4hExJTEScJ5 nDbbPhGVeRmUmF9LEoMG8mRICBKUqHVVzFEd0uqgvu7tVM8jAZJmwo8R X-Gm-Gg: AeBDievdtSssvpoRxYADX6FoqIjhnnuiYCIbQ37WOG7iPlY8vhiseIQBTP1PibVOjnl cCDyoAkExX+aJod34KPzOaQ73X7xOIfEs/yAIbUa1eDBL6HH0xp7LXUb7GDEpP31Ci0KoqYQ432 XdtXxMKpKbyyl7yHdDNRepksDlJxRJ3Lk51vaBvlH5+1Rf4ziEx4cEON6y4kC6riW3FVvkRPhRw 3tHLDJCtmhjSzUIclxfE+OmNyJv0X95vvkPPQeXovC6gz8jiLjPX/Sk8xjGRt1lXd0vhAnPFZiv Yr4ZPaLQLI+A+eeMXI9v5mYZpv39jh78Wn59VAcVf/qrVBYiXqkA8fCGmRCE2Hak8akn9AqhPZA SiKjmy6YuhlVt1rasD60WO4Mmk7Vv8mXYMoR+E5JVrMHfiB4NTkig5kHbukk/05KH86hfDtCIU7 9glvdYhU5oTpvQZ8Bz99jHvnFY1TuDYVGW+fh2ZOk6fZz7QaS2UczELEz7JlciBOSevUWqzPwSe 89pE/AxU7oWkA== X-Received: by 2002:a05:6a20:728c:b0:39b:8b8b:39ce with SMTP id adf61e73a8af0-3a08d8a8993mr19982573637.28.1776773314253; Tue, 21 Apr 2026 05:08:34 -0700 (PDT) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c7976f8f4e8sm10256209a12.1.2026.04.21.05.08.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 05:08:33 -0700 (PDT) From: zhidao su X-Google-Original-From: zhidao su To: kprateek.nayak@amd.com, jstultz@google.com Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, soolaugust@gmail.com, suzhidao@xiaomi.com Subject: Re: [PATCH] sched/proxy_exec: Limit find_proxy_task() chain depth to prevent CPU hang Date: Tue, 21 Apr 2026 20:08:26 +0800 Message-ID: <20260421120826.1322225-1-suzhidao@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <1df0e505-add4-4b7d-8e09-bc52402da617@amd.com> References: <1df0e505-add4-4b7d-8e09-bc52402da617@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hello John, Prateek, On Tue, Apr 21, 2026 at 08:43 AM +0530, K Prateek Nayak wrote: > As an alternate approach, when traversing blocked_on links, can we > start deactivating the chain if we encounter rq->donor again as owner > in find_proxy_task() loop? > > That way we go back to triggering the hung task detector and if someone > has a stack that depends on it, it'll continue to work fine while also > avoiding this lockup. Thanks for the suggestion. I've implemented and tested this approach. On John's point about BUG(): I agree lock cycles are a serious bug, but deactivating the donor preserves mutex_lock_interruptible() recovery paths and avoids a hard system stop for what could be an application-level bug. The WARN_ONCE + hung-task splat provides sufficient visibility. Changes from v1: - Replace proxy_resched_idle() with proxy_deactivate() on both the depth-exceeded path and the new cycle-detected path. proxy_resched_idle() returns rq->idle, causing __schedule() to immediately re-select the same donor and re-enter find_proxy_task(), creating a soft loop with no forward progress. (John Stultz) - Add owner == donor cycle detection immediately after resolving owner from blocked_on. This catches A->B->...->A at the first chain closure; no visited set needed. (K Prateek Nayak) - Raise MAX_PROXY_CHAIN_DEPTH from 64 to 1024 to match rt-mutex's max_lock_depth. (John Stultz) Tested with pe_cycle_kmod (two kthreads pinned to CPU 0, each holding one mutex and trying to acquire the other, virtme-ng, CONFIG_LOCKDEP=n): [ 109.057659] sched/pe: deadlock cycle detected, pid 154 [ 109.057687] WARNING: CPU: 0 PID: 155 at kernel/sched/core.c:7392 find_proxy_task+0x.../... ... [ 246.820220] INFO: task pe_cycle_A:154 blocked for more than 122 seconds. [ 246.820238] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.820358] INFO: task pe_cycle_A:154 is blocked on a mutex likely owned by task pe_cycle_B:155. [ 246.820360] INFO: task pe_cycle_B:155 blocked for more than 122 seconds. [ 246.820433] INFO: task pe_cycle_B:155 is blocked on a mutex likely owned by task pe_cycle_A:154. EXEC_DONE (VM continued normally throughout) cycle detection fires immediately (~1ms after deadlock forms), donor is deactivated, hung-task detector fires after 122s as expected. Will send v2 once this direction is confirmed. Thanks, zhidao su