From: Lance Yang <lance.yang@linux.dev>
To: Aaron Tomlin <atomlin@atomlin.com>
Cc: sean@ashe.io, akpm@linux-foundation.org,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
joel.granados@kernel.org, pmladek@suse.com, mhiramat@kernel.org
Subject: Re: [v5 PATCH 1/2] hung_task: Introduce helper for hung task warning
Date: Fri, 2 Jan 2026 11:40:24 +0800 [thread overview]
Message-ID: <b0b3d456-233d-413f-ac05-5636c4184a9e@linux.dev> (raw)
In-Reply-To: <5n62kpipakytp6u7be24ltvhwqryztoe5goorgrnserwnrwfyt@owbkj3pezq55>
On 2026/1/2 03:28, Aaron Tomlin wrote:
> On Thu, Jan 01, 2026 at 05:49:59PM +0800, Lance Yang wrote:
>> I am wondering whether we should leave that code as-is to
>> avoid unnecessary churn ...
>>
>> That code was not particularly complex or duplicated :)
>
> Hi Lance,
>
> While I agree the current logic is simple, separating the verbose reporting
> from the detection loop significantly improves the readability of
> check_hung_task(). This refactoring introduces no runtime overhead
> (static inline) while providing a cleaner, encapsulated structure for any
> future diagnostic enhancements.
For a single-use diagnostic block, I still think this refactoring
does not add much practical value ...
Let's leave the code alone - it's probably not worth the churn :)
next prev parent reply other threads:[~2026-01-02 3:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 0:41 [v5 PATCH 0/2] hung_task: Provide runtime reset interface for hung task detector Aaron Tomlin
2025-12-31 0:41 ` [v5 PATCH 1/2] hung_task: Introduce helper for hung task warning Aaron Tomlin
2026-01-01 9:49 ` Lance Yang
2026-01-01 19:28 ` Aaron Tomlin
2026-01-02 3:40 ` Lance Yang [this message]
2026-01-02 19:02 ` Aaron Tomlin
2025-12-31 0:41 ` [v5 PATCH 2/2] hung_task: Enable runtime reset of hung_task_detect_count Aaron Tomlin
2026-01-01 9:46 ` Lance Yang
2026-01-01 23:14 ` Joel Granados
2026-01-02 1:24 ` Aaron Tomlin
2026-01-05 10:53 ` Joel Granados
2026-01-05 14:42 ` Aaron Tomlin
2026-01-06 11:36 ` Joel Granados
2026-01-07 1:49 ` Aaron Tomlin
2026-01-06 11:51 ` Joel Granados
2026-01-07 3:37 ` Aaron Tomlin
2026-01-08 14:41 ` Petr Mladek
2026-01-09 13:50 ` Lance Yang
2026-01-12 13:13 ` Petr Mladek
2026-01-12 14:43 ` Lance Yang
2026-01-15 2:20 ` Aaron Tomlin
2026-01-10 15:55 ` Aaron Tomlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0b3d456-233d-413f-ac05-5636c4184a9e@linux.dev \
--to=lance.yang@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=atomlin@atomlin.com \
--cc=gregkh@linuxfoundation.org \
--cc=joel.granados@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=pmladek@suse.com \
--cc=sean@ashe.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.