linux-kernel - Re: [PATCH] atomic: Specify natural alignment for atomic

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: <c8851682-25f1-f594-e30f-5b62e019d37b@linux-m68k.org>
Date: Mon, 25 Aug 2025 14:07:32 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: Lance Yang <ioworker0@...il.com>
cc: akpm@...ux-foundation.org, geert@...ux-m68k.org, lance.yang@...ux.dev, 
    linux-kernel@...r.kernel.org, mhiramat@...nel.org, oak@...sinkinet.fi, 
    peterz@...radead.org, stable@...r.kernel.org, will@...nel.org
Subject: Re: [PATCH] atomic: Specify natural alignment for atomic_t

On Mon, 25 Aug 2025, Lance Yang wrote:

> 
> Perhaps we should also apply the follwoing?
> 
> diff --git a/include/linux/hung_task.h b/include/linux/hung_task.h
> index 34e615c76ca5..940f8f3558f6 100644
> --- a/include/linux/hung_task.h
> +++ b/include/linux/hung_task.h
> @@ -45,7 +45,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 +53,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);
>  }
> 
> Let the feature gracefully do nothing on that ;)
> 

This is poor style indeed.

The conditional you've added to the hung task code has no real relevance 
to hung tasks. It doesn't belong there.

Of course, nobody wants that sort of logic to get duplicated at each site 
affected by the architectural quirk in question. Try to imagine if the 
whole kernel followed your example, and such unrelated conditionals were 
scattered across code base for a few decades. Now imagine trying to work 
on that code.

You can see special cases for architectural quirks in drivers, but we do 
try to avoid them. And this is not a driver.