Message-ID: <3e0b7551-698f-4ef6-919b-ff4cbe3aa11c@linux.dev>
Date: Thu, 9 Oct 2025 10:01:18 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
 Eero Tamminen <oak@...sinkinet.fi>,
 Kent Overstreet <kent.overstreet@...ux.dev>, amaindex@...look.com,
 anna.schumaker@...cle.com, boqun.feng@...il.com, ioworker0@...il.com,
 joel.granados@...nel.org, jstultz@...gle.com, leonylgao@...cent.com,
 linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
 longman@...hat.com, mhiramat@...nel.org, mingo@...hat.com,
 mingzhe.yang@...com, peterz@...radead.org, rostedt@...dmis.org,
 Finn Thain <fthain@...ux-m68k.org>, senozhatsky@...omium.org,
 tfiga@...omium.org, will@...nel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/1] hung_task: fix warnings caused by unaligned lock
 pointers

@Andrew, what's your call on this?

I think we fundamentally disagree on whether this fix for known
false-positive warnings is needed for -stable.

Rather than continuing this thread, let's just ask the maintainer.

Thanks,
Lance

On 2025/10/9 05:55, Finn Thain wrote:
> 
> On Wed, 8 Oct 2025, Lance Yang wrote:
> 
>> On 2025/10/8 18:12, Finn Thain wrote:
>>>
>>> On Wed, 8 Oct 2025, Lance Yang wrote:
>>>
>>>>
>>>> In other words, we are not just fixing the bug reported by Eero and
>>>> Geert, but correcting the blocker tracking mechanism's flawed
>>>> assumption for -stable ;)
>>>>
>>>> If you feel this doesn't qualify as a fix, I can change the Fixes:
>>>> tag to point to the original commit that introduced this flawed
>>>> mechanism instead.
>>>>
>>>
>>> That's really a question for the bug reporters. I don't personally
>>> have a problem with CONFIG_DETECT_HUNG_TASK_BLOCKER so I can't say
>>> whether the fix meets the requirements set in
>>> Documentation/process/stable-kernel-rules.rst. And I still don't know
>>
>> I'm a bit confused, as I recall you previously stating that "It's wrong
>> and should be fixed"[1].
>>
> 
> You took that quote out of context. Please go and read it again.
> 
>> To clarify, is your current position that it should be fixed in general,
>> but the fix should not be backported to -stable?
>>
> 
> To clarify, what do you mean by "it"? Is it the commentary discussed in
> [1]? The misalignment of atomics? The misalignment of locks? The alignment
> assumptions in your code? The WARN reported by Eero and Geert?
> 
>> If so, then I have nothing further to add to this thread and am happy to
>> let the maintainer @Andrew decide.
>>
>>> what's meant by "unnecessary warnings in a few unexpected cases".
>>
>> The blocker tracking mechanism will trigger a warning when it encounters
>> any unaligned lock pointer (e.g., from a packed struct). I don't think
>> that is the expected behavior.
> 
> Sure, no-one was expecting false positives.
> 
> I think you are conflating "misaligned" with "not 4-byte aligned". Your
> algorithm does not strictly require natural alignment, it requires 4-byte
> alignment of locks.
> 
> Regarding your concern about packed structs, please re-read this message:
> https://lore.kernel.org/all/CAMuHMdV-AtPm-W-QUC1HixJ8Koy_HdESwCCOhRs3Q26=wjWwog@mail.gmail.com/
> 
> AFAIK the problem with your code is nothing more than the usual difficulty
> encountered when porting between architectures that have different
> alignment rules for scalar variables.
> 
> Therefore, my question about the theoretical nature of the problem comes
> down to this.
> 
> Is the m68k architecture the only one producing actual false positives?
> 
> Do you know of actual instances of locks in packed structs?
> 
>> Instead, it should simply skip any unaligned pointer it cannot handle.
>> For the stable kernels, at least, this is the correct behavior.
>>
> 
> Why? Are users of the stable branch actually affected?
> 
>> [1]
>> https://lore.kernel.org/lkml/6ec95c3f-365b-e352-301b-94ab3d8af73c@linux-m68k.org/
>>
>>

Powered by blists - more mailing lists