[PATCH] ARM: Thumb2: align ALT_UP() sections sufficiently

[Russell King (Oracle)]

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 at armlinux.org.uk> 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!