From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 5400839E6EB for ; Thu, 30 Jul 2026 04:47:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785386870; cv=none; b=Y/y/sBwchgCX678jVOg5nIZ/8Z2qnr55qAEpYcWcSM4xNxmX/7SyQv86dxBHu/cqFzopkm/vonPEeFZI9KxhLmx8fxoKE1APmWuZSDKTJ4OteaEFsW4HdfxRGOOzfo3Ryxtn44gg/Mtx7sGf9xkaJw2B9q8S2zGwuE4iZMkAazw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785386870; c=relaxed/simple; bh=qNuKL1lxAg5/mFWfFtdGHKL0U7LzFfnZI7sd9UPG/ts=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=Vt/HGTLEACGdIhyqJ1mXYsG8WVeQM1CPKPMnjX/V85pmHD/+F9A9dufySoJaSIbmT3ky6AoQpNdRQQ6vZmmPCijf7QmucaYRXv3eBypnhTYZcNVCvJKVcZrZBNoWj7rl6GpUltVE5Bs4+QA2i3wZ1qem4Pvb46rdM5p4jHYkc3w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=IsbcKYc3; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="IsbcKYc3" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785386862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YTVTymDu18muxi1dLqfJfR4TRVQHAWnDxTaP9G68Wk0=; b=IsbcKYc3RFMI+PB16W0vkqNuH3fAThJDJVWVzvQiKNR+OjsE/sTJAsAPr8aWTOUo1N7arw CJuxJfAZdx8zK9kzViPVkZr5HeuEvoPW+3lZtztnrQIClbLIpYm96LyEtm7T8qCCQaNRdA 1ux7PTOQ4r79dr0iUlb9YOPs0zUQupY= From: Lance Yang To: wangxb12@chinatelecom.cn Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, mhiramat@kernel.org, lance.yang@linux.dev, pmladek@suse.com Subject: Re: [PATCH] hung_task: update DETECT_HUNG_TASK_BLOCKER Kconfig help Date: Thu, 30 Jul 2026 12:47:35 +0800 Message-Id: <20260730044735.9943-1-lance.yang@linux.dev> In-Reply-To: <20260730031751.67840-1-wangxb12@chinatelecom.cn> References: <20260730031751.67840-1-wangxb12@chinatelecom.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT +Cc Petr get_maintainer.pl is your friend :) please use it next time. On Thu, Jul 30, 2026 at 11:17:51AM +0800, Xibo Wang wrote: >The help text still says the feature only covers mutexes, but blocker >tracking has since been extended to semaphores and rwsems. Update the >description to match the supported lock types. Thanks! >Signed-off-by: Xibo Wang >--- > lib/Kconfig.debug | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > >diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >index 1244dcac2294..c2ffaff918d1 100644 >--- a/lib/Kconfig.debug >+++ b/lib/Kconfig.debug >@@ -1320,10 +1320,11 @@ config DETECT_HUNG_TASK_BLOCKER > depends on !PREEMPT_RT > default y > help >- Say Y here to show the blocker task's stacktrace who acquires >- the mutex lock which "hung tasks" are waiting. >- This will add overhead a bit but shows suspicious tasks and >- call trace if it comes from waiting a mutex. >+ Say Y here to show the blocker task's stacktrace that holds >+ the lock which "hung tasks" are waiting on. Supported lock >+ types are mutex, semaphore, and rwsem. >+ This will add a bit of overhead but shows suspicious tasks and >+ call traces if it comes from waiting on one of these locks. "holds the lock" seems too strong here... For semaphores we only have the last holder, and rwsem owner tracking is best-effort for readers. So this is only a possible blocker, not necessarily the current lock holder. I'd rather go with: Say Y here to show a possible blocker task's stacktrace when a hung task is waiting on a mutex, semaphore, or rwsem. This will add a bit of overhead but shows suspicious tasks and call traces for waits on one of these locks. Cheers, Lance