linux-kernel - Re: [PATCH 1/1] hung_task: fix warnings by enforcing alignment on lock structures

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: <0e0d52b4-8c69-9774-c69d-579985c0f0ee@linux-m68k.org>
Date: Sun, 24 Aug 2025 15:57:51 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: Lance Yang <lance.yang@...ux.dev>
cc: akpm@...ux-foundation.org, mhiramat@...nel.org, 
    kernel test robot <lkp@...el.com>, geert@...ux-m68k.org, 
    senozhatsky@...omium.org, oe-kbuild-all@...ts.linux.dev, 
    amaindex@...look.com, anna.schumaker@...cle.com, boqun.feng@...il.com, 
    ioworker0@...il.com, joel.granados@...nel.org, jstultz@...gle.com, 
    kent.overstreet@...ux.dev, leonylgao@...cent.com, 
    linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org, 
    longman@...hat.com, mingo@...hat.com, mingzhe.yang@...com, 
    oak@...sinkinet.fi, rostedt@...dmis.org, tfiga@...omium.org, 
    will@...nel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/1] hung_task: fix warnings by enforcing alignment on
 lock structures


On Sun, 24 Aug 2025, Lance Yang wrote:

> 
> The blocker tracking mechanism operates on pointers to higher-level 
> locks (like struct mutex), as that is what is stored in the 
> task_struct->blocker field. It does not operate on the lower-level 
> arch_spinlock_t inside it.
> 

Perhaps you are aware that the minimum alignment of the struct is at least 
the minimum alignment of the first member. I believe that the reason why 
the lock is always the first member is that misaligned accesses would harm 
performance.

I really don't know why you want to argue about fixing this.

> While we could track the internal arch_spinlock_t, that would break 
> encapsulation.
>

Would it.

> The hung task detector should remain generic and not depend on 
> lock-specific implementation details ;)
> 

OK, like a new class derived from bitfield and pointer? Is that what you 
mean by "generic" and "encapsulated"?