summaryrefslogtreecommitdiff
path: root/arch/m68k
diff options
context:
space:
mode:
authorGreg Ungerer <gerg@linux-m68k.org>2020-10-12 13:58:41 +1000
committerGreg Ungerer <gerg@linux-m68k.org>2020-12-07 09:37:58 +1000
commit670d39657ca355615428d176e9de4e69bfb3cf9b (patch)
tree7331d9f6e32cf859563a371442a0d2a119d0c547 /arch/m68k
parent0477e92881850d44910a7e94fc2c46f96faa131f (diff)
downloadlwn-670d39657ca355615428d176e9de4e69bfb3cf9b.tar.gz
lwn-670d39657ca355615428d176e9de4e69bfb3cf9b.zip
m68knommu: align BSS section to 4-byte boundaries
The kernel start up code for all of the nommu m68k types expects the BSS section to be on a 4-byte boundary, and to be a whole number of 32bit words. The BSS initialization loop sets 32bit sized quantities and has no provision for odd or unaligned accesses. The alignment and size of the BSS has historically worked out to be 4-byte aligned and sized - although no explicit alignment or size was specified in the linker script. So the BSS zeroing code worked as expected. A problem was first observed after commit 7273ad2b08f8 ("kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y"). Some kernel builds, depending on exact configuration, then tended to generate even sized BSS sections - which is valid on m68k - but our BSS init code could not handle properly. The simplest and smallest solution is to align and size the BSS appropriately. Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Diffstat (limited to 'arch/m68k')
-rw-r--r--arch/m68k/kernel/vmlinux-nommu.lds2
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/m68k/kernel/vmlinux-nommu.lds b/arch/m68k/kernel/vmlinux-nommu.lds
index 7b975420c3d9..730bb653f9c1 100644
--- a/arch/m68k/kernel/vmlinux-nommu.lds
+++ b/arch/m68k/kernel/vmlinux-nommu.lds
@@ -82,7 +82,7 @@ SECTIONS {
__init_end = .;
}
- BSS_SECTION(0, 0, 0)
+ BSS_SECTION(4, 0, 4)
_end = .;