linux-kernel - Re: [PATCH v4 1/2] hung_task: Show the blocker task if the task is hung on mutex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <sp5amdg3pewlnhcigeitslfdmf4sprss6fia4vrtx6dwixotlf@lfuama2h2nrw>
Date: Wed, 26 Feb 2025 13:38:19 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Will Deacon <will@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Boqun Feng <boqun.feng@...il.com>, Waiman Long <longman@...hat.com>, 
	Joel Granados <joel.granados@...nel.org>, Anna Schumaker <anna.schumaker@...cle.com>, 
	Lance Yang <ioworker0@...il.com>, Kent Overstreet <kent.overstreet@...ux.dev>, 
	Yongliang Gao <leonylgao@...cent.com>, Steven Rostedt <rostedt@...dmis.org>, 
	Tomasz Figa <tfiga@...omium.org>, Sergey Senozhatsky <senozhatsky@...omium.org>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/2] hung_task: Show the blocker task if the task is
 hung on mutex

On (25/02/25 16:02), Masami Hiramatsu (Google) wrote:
> The "hung_task" shows a long-time uninterruptible slept task, but most
> often, it's blocked on a mutex acquired by another task. Without
> dumping such a task, investigating the root cause of the hung task
> problem is very difficult.
> 
> This introduce task_struct::blocker_mutex to point the mutex lock
> which this task is waiting for. Since the mutex has "owner"
> information, we can find the owner task and dump it with hung tasks.
> 
> Note: the owner can be changed while dumping the owner task, so
> this is "likely" the owner of the mutex.

I assume another possibility can be that the owner is still around,
let's say a kworker that simply forgot to mutex_unlock(), so we'll
get its backtrace but it can be misleading, because kworker in
question might be doing something completely unrelated.  But this
is still better than nothing.

FWIW
Reviewed-by: Sergey Senozhatsky <senozhatsky@...omium.org>