On Tue, Jan 18, 2022 at 12:32:55PM +0100, Ard Biesheuvel wrote: > On Tue, 18 Jan 2022 at 12:21, Russell King (Oracle) > <linux@xxxxxxxxxxxxxxx> wrote: > > > > On Tue, Jan 18, 2022 at 11:27:56AM +0100, Ard Biesheuvel wrote: > > > When building for Thumb2, the .alt.smp.init sections that are emitted by > > > the ALT_UP() patching code may not be 32-bit aligned, even though the > > > fixup_smp_on_up() routine expects that. This results in alignment faults > > > at module load time, which need to be fixed up by the fault handler. > > > > > > So let's align those sections explicitly, and avoid this from occurring. > > > > Are you seeing a problem that this patch fixes? > > > > This really should not matter. .alt.smp.init contents are always a whole > > number of 32-bit words. These are gathered by the linker into the > > .init.smpalt section, so the contents should always be a whole number > > of 32-bit words. > > > > This follows the .init.tagtable section, which is also a 32-bit word > > aligned structure built by the linker... which follows the > > .init.arch.info section and .init.proc.info sections which all have > > 32-bit alignment requirements. > > > > This only affects modules, not the core kernel. The .alt.smp.init > section in a module is visible to the module loader, which means the > module loader will make no attempt to position it at a 32-bit aligned > address if the ELF alignment is only 16 bits, which appears to be the > default in my Thumb2 build [gcc version 10.3.1 20211117 (Debian > 10.3.0-13)] > > I only spotted this because do_fixup_smp_on_up() was shown as the most > recent in-kernel fixup location in /proc/cpu/alignment. Ok, thanks for the explanation. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
