From: Lance Yang <lance.yang@linux.dev>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
akpm@linux-foundation.org
Cc: fthain@linux-m68k.org, geert@linux-m68k.org,
senozhatsky@chromium.org, amaindex@outlook.com,
anna.schumaker@oracle.com, boqun.feng@gmail.com,
ioworker0@gmail.com, joel.granados@kernel.org,
jstultz@google.com, kent.overstreet@linux.dev,
leonylgao@tencent.com, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, longman@redhat.com,
mingo@redhat.com, mingzhe.yang@ly.com, oak@helsinkinet.fi,
peterz@infradead.org, rostedt@goodmis.org, tfiga@chromium.org,
will@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/1] hung_task: fix warnings caused by unaligned lock pointers
Date: Tue, 26 Aug 2025 13:11:00 +0800 [thread overview]
Message-ID: <ca2785fa-ae29-44c9-8975-d7c98cd3792a@linux.dev> (raw)
In-Reply-To: <20250826134948.4f5f5aa74849e7f56f106c83@kernel.org>
Thanks for the review!
On 2025/8/26 12:49, Masami Hiramatsu (Google) wrote:
> On Sat, 23 Aug 2025 13:00:36 +0800
> Lance Yang <lance.yang@linux.dev> wrote:
>
>> From: Lance Yang <lance.yang@linux.dev>
>>
>> The blocker tracking mechanism assumes that lock pointers are at least
>> 4-byte aligned to use their lower bits for type encoding.
>>
>> However, as reported by Geert Uytterhoeven, some architectures like m68k
>> only guarantee 2-byte alignment of 32-bit values. This breaks the
>> assumption and causes two related WARN_ON_ONCE checks to trigger.
>>
>> To fix this, the runtime checks are adjusted. The first WARN_ON_ONCE in
>> hung_task_set_blocker() is changed to a simple 'if' that returns silently
>> for unaligned pointers. The second, now-invalid WARN_ON_ONCE in
>> hung_task_clear_blocker() is then removed.
>>
>> Thanks to Geert for bisecting!
>>
>> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> Closes: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr8_g58Rc1_0g@mail.gmail.com
>> Fixes: e711faaafbe5 ("hung_task: replace blocker_mutex with encoded blocker")
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>
> Looks good to me. I think we can just ignore it for
> this debugging option.
Exactly. As Peter pointed out, most architectures would trap on the
unaligned atomic access long before this check is ever reached.
So this patch only affects the few architectures that don't trap,
gracefully silencing the warning there. This makes it a clean and safe
fix for backporting.
Cheers,
Lance
>
> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> Thank you,
>
>> ---
>> include/linux/hung_task.h | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/hung_task.h b/include/linux/hung_task.h
>> index 34e615c76ca5..69640f266a69 100644
>> --- a/include/linux/hung_task.h
>> +++ b/include/linux/hung_task.h
>> @@ -20,6 +20,10 @@
>> * always zero. So we can use these bits to encode the specific blocking
>> * type.
>> *
>> + * Note that on architectures like m68k with only 2-byte alignment, the
>> + * blocker tracking mechanism gracefully does nothing for any lock that is
>> + * not 4-byte aligned.
>> + *
>> * Type encoding:
>> * 00 - Blocked on mutex (BLOCKER_TYPE_MUTEX)
>> * 01 - Blocked on semaphore (BLOCKER_TYPE_SEM)
>> @@ -45,7 +49,7 @@ static inline void hung_task_set_blocker(void *lock, unsigned long type)
>> * If the lock pointer matches the BLOCKER_TYPE_MASK, return
>> * without writing anything.
>> */
>> - if (WARN_ON_ONCE(lock_ptr & BLOCKER_TYPE_MASK))
>> + if (lock_ptr & BLOCKER_TYPE_MASK)
>> return;
>>
>> WRITE_ONCE(current->blocker, lock_ptr | type);
>> @@ -53,8 +57,6 @@ static inline void hung_task_set_blocker(void *lock, unsigned long type)
>>
>> static inline void hung_task_clear_blocker(void)
>> {
>> - WARN_ON_ONCE(!READ_ONCE(current->blocker));
>> -
>> WRITE_ONCE(current->blocker, 0UL);
>> }
>>
>> --
>> 2.49.0
>>
>
>
next prev parent reply other threads:[~2025-08-26 5:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 14:59 [PATCH v5 0/3] hung_task: extend blocking task stacktrace dump to semaphore Lance Yang
2025-04-14 14:59 ` [PATCH v5 1/3] hung_task: replace blocker_mutex with encoded blocker Lance Yang
2025-04-14 21:36 ` Andrew Morton
2025-04-15 3:44 ` Lance Yang
2025-04-14 14:59 ` [PATCH v5 2/3] hung_task: show the blocker task if the task is hung on semaphore Lance Yang
2025-08-22 7:38 ` Geert Uytterhoeven
2025-08-22 15:18 ` Lance Yang
2025-08-22 15:37 ` Geert Uytterhoeven
2025-08-22 16:42 ` Lance Yang
2025-08-23 0:27 ` Finn Thain
2025-08-23 4:47 ` Lance Yang
2025-08-23 5:00 ` [PATCH 1/1] hung_task: fix warnings caused by unaligned lock pointers Lance Yang
2025-08-26 4:49 ` Masami Hiramatsu
2025-08-26 5:11 ` Lance Yang [this message]
2025-08-23 7:40 ` [PATCH 1/1] hung_task: fix warnings by enforcing alignment on lock structures Lance Yang
2025-08-23 21:53 ` kernel test robot
2025-08-24 0:47 ` Finn Thain
2025-08-24 3:03 ` Lance Yang
2025-08-24 4:18 ` Finn Thain
2025-08-24 5:02 ` Lance Yang
2025-08-24 5:57 ` Finn Thain
2025-08-24 6:18 ` Lance Yang
2025-08-26 5:02 ` Masami Hiramatsu
2025-08-26 5:16 ` Lance Yang
2025-08-23 7:49 ` [PATCH v5 2/3] hung_task: show the blocker task if the task is hung on semaphore Lance Yang
2025-04-14 14:59 ` [PATCH v5 3/3] samples: extend hung_task detector test with semaphore support Lance Yang
2025-04-14 21:38 ` [PATCH v5 0/3] hung_task: extend blocking task stacktrace dump to semaphore Andrew Morton
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=ca2785fa-ae29-44c9-8975-d7c98cd3792a@linux.dev \
--to=lance.yang@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=amaindex@outlook.com \
--cc=anna.schumaker@oracle.com \
--cc=boqun.feng@gmail.com \
--cc=fthain@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=ioworker0@gmail.com \
--cc=joel.granados@kernel.org \
--cc=jstultz@google.com \
--cc=kent.overstreet@linux.dev \
--cc=leonylgao@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=longman@redhat.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=mingzhe.yang@ly.com \
--cc=oak@helsinkinet.fi \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=stable@vger.kernel.org \
--cc=tfiga@chromium.org \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).