Hi Eero,
On Tue, 26 Aug 2025 at 17:22, Eero Tamminen oak@helsinkinet.fi wrote:
On 25.8.2025 5.03, Finn Thain wrote:
Some recent commits incorrectly assumed the natural alignment of locks. That assumption fails on Linux/m68k (and, interestingly, would have failed on Linux/cris also). This leads to spurious warnings from the hang check code. Fix this bug by adding the necessary 'aligned' attribute.
[...]
Reported-by: Eero Tamminen oak@helsinkinet.fi Closes: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr8_g58Rc... Fixes: e711faaafbe5 ("hung_task: replace blocker_mutex with encoded blocker") Signed-off-by: Finn Thain fthain@linux-m68k.org
I tested this on m68k using GCC and it fixed the problem for me. AFAIK, the other architectures naturally align ints already so I'm expecting to see no effect there.
Yes, it fixes both of the issues (warnings & broken console): Tested-by: Eero Tamminen oak@helsinkinet.fi
(Emulated Atari Falcon) boot up performance with this is within normal variation.
On 23.8.2025 10.49, Lance Yang wrote:
Anyway, I've prepared two patches for discussion, either of which should fix the alignment issue :)
Patch A[1] adjusts the runtime checks to handle unaligned pointers. Patch B[2] enforces 4-byte alignment on the core lock structures.
Both tested on x86-64.
[1]
https://lore.kernel.org/lkml/20250823050036.7748-1-lance.yang@linux.dev
[2] https://lore.kernel.org/lkml/20250823074048.92498-1- lance.yang@linux.dev
Same goes for both of these, except that removing warnings makes minimal kernel boot 1-2% faster than 4-aligning the whole struct.
That is an interesting outcome! So the gain of naturally-aligning the lock is more than offset by the increased cache pressure due to wasting (a bit?) more memory.
Do you know what was the impact on total kernel size? Thanks!
Gr{oetje,eeting}s,
Geert