[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <iln7qlvkza24tpcre6emzsjxjynotew6iha6pshg3c3yiz65ef@oculodcngg6y>
Date: Wed, 30 Jul 2025 18:46:20 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Lance Yang <lance.yang@...ux.dev>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
"Masami Hiramatsu (Google)" <mhiramat@...nel.org>, 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>, 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/07/30 17:22), Lance Yang wrote:
[..]
> We should also consider that in many real-world cases, the blocking
> chain is just one level deep
I don't know if this is the case, but consider example:
- task T1 owns lock L1 and is blocked (e.g. on a very huge/slow I/O)
- tasks T2..TN are blocked on L1
There will be N backtraces of T1, with every T2..TN backtrace, which
on a system with small pstore or very slow serial console can in theory
be a little problematic.
Powered by blists - more mailing lists