From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) (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 04E12317143 for ; Tue, 21 Apr 2026 12:02:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776772953; cv=none; b=jK6fdAcWhAD/cG0ZXrwUy2tYZNKp7RKDxASsTXpeqBGW9QdqZTyOFQPA6Wt1u7eC3BuNwTNOzz9OVBgU9UpIgwRW00+pUdzhxTrdHohQJ+T9vUcVqLIUyOmTfEYctQlh8K+ythaVg3a/W56CrYPDOAyrrK3sEOGxTU+OX4OfrN0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776772953; c=relaxed/simple; bh=9aiftvXoesT9lKQM7LcL5I6QzIcdg1rnjxi4DXhxHTg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=r0C5c3QJ0RPk/FJRRHOIu2HqnSe04a+2uKb1DH1bpGM9tnaPPdymeRxldfZpLgJyAFNZ9GU/+K6HRRHAubQ3JAh1cj9e9e1gXjNQZlSpAtZsg/rSnR0iE23RUfy0+8aRo1HWxeyt6HX+SghG5hQI1N7QsgYpFUvZXRz/dIomLWE= 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=TOgwkW0x; arc=none smtp.client-ip=209.85.216.51 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="TOgwkW0x" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-35d94f4ee36so2449509a91.3 for ; Tue, 21 Apr 2026 05:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776772951; x=1777377751; 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=HSidNW0AnpRS0ZS5cDiNcXsYmjCYdzldLcECox0Iujs=; b=TOgwkW0x0EWL0hwzvW9B3AJcJfqQLLoz65r6B/f+3NjMRkxhIaRCFkUZ9ceBz4UyXz ewYuhYrLA1m/miSy6plEfL7eqYkfza5QcIQqIC9gXh9TDe4KNgW3G5+sOicl39ODg76I oP5JkIQWvCAErcv98VbK9h5Ba2MduRA6y5tnFmhWSngpcX6I+ogF1PDYv9YNOTn8aCEc oUm20ii+A04mRZwlQ8IpiZ5sGzzmFdHiixkEv4z/gwBdCApx1hBeaGYQAW/t4dzU0SBj aaAAeh8A0R4o03FeQ1yEFvrQgBUAtKDExQ6862aS97OroNlMItO6lkqmG3bfAKj83m2a aaAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776772951; x=1777377751; 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=HSidNW0AnpRS0ZS5cDiNcXsYmjCYdzldLcECox0Iujs=; b=cbHkfcSyFSsvr7eLXD/hTIjDQyUv5vep/9qC9zt/P+WoV/LD/mQ0iCRv4uVkMAOogl FDfUsmv7Fuc56y4a2ZzQLnitMe2xgqDHsPQF8yWQQsXjJpPvo2xUE5PX0E9jME6rc3X6 B34p33mSGV27osyDQS6VEo5KGE+lAXtxPu6TpqTBv/Ffky+IA6A19PWzgsUG9yk1Tpar 54hB0l4oHzOhG31bBA10p4QMh75K+w3IrKKzR9oHCcSo1K5BZ5aBtaJbAfX2TsPLtK5M e4iNTus3Z6WGFQQeMivdHn+chsYUSuP0mhrZCYHFEkBHZ9ZOLputyRNdDUAxOYCkoXh1 xtzA== X-Gm-Message-State: AOJu0Yy3Klk4GryuSQDFb/bO2h/Wq81bhESHwi88YRPV4zXFLkkidgfl Tvrpb3dG945vhyTHG5uUV2JVdD3Ki7srfdHLh55Moiv6J1+lSfXNg4px X-Gm-Gg: AeBDieunN3/G4V1idu3VRNx5oSBn/0WPfX6qltRL7xmJumZDTTblc05i/0ARB/9qr75 wxM3OYAqQP6UghLSn+gc4mF1biWiXrvNle8Xb1wPAXrRfUNPDHYO3q22fEpAVr238lg4sV4N9A+ 5OE0Y2ATAhe13hmXJCMYul7M5H51ZWMSkk8HoHoSaNvT/zmKvqZlatRguIxtRJ4DmR7MbmgVKFW UAedAimGasU9nHVCYgAbNyltv4oMoaNKgYge34W5mYxV+w/K6DTsO7eT8GZqNOMojXSrcJKE8uE kj5dzdfv1VlKXqkLI8fDwp7ESQygFwjGUFe7gyIrJvEHaDOxorrMEjxR3ev7APd4JN40y9Oei7/ MmVsTZzc6vl5IfHKX8Y4GNG1QZzBZPsnqnFZc4OGFzVPmHMTu6ZC4j5IoOyLASoAaRjGcbW8Umn PafhthuGxUz04x2DTOiqbkxyTwaadj/kjJQCBwA/zzDkC/7zL6byRqNtiY95yDtTn5jouT+i+2Z X8lkZXSeOe3kQ== X-Received: by 2002:a17:90b:350f:b0:359:8e5e:43de with SMTP id 98e67ed59e1d1-3614049358emr18801213a91.22.1776772951194; Tue, 21 Apr 2026 05:02:31 -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 98e67ed59e1d1-361419739dfsm14251517a91.13.2026.04.21.05.02.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 05:02:30 -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:02:22 +0800 Message-ID: <20260421120222.1308719-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. (Prateek Sood) - 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