64-bit allyesconfig builds fail with

x86_64-linux-ld: kernel image bigger than KERNEL_IMAGE_SIZE

Bisect points to commit 6f110a5e4f99 ("Disable SLUB_TINY for build
testing") as the responsible commit. Reverting that patch does indeed
fix the problem. Further analysis shows that disabling SLUB_TINY enables
KASAN, and that KASAN is responsible for the image size increase.

Solve the build problem by disabling the image size check for test
builds.

While at it, fix typo in associated comment (sink -> sync).

Fixes: 6f110a5e4f99 ("Disable SLUB_TINY for build testing")
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v4: Added comment explaining the change
    Fixed sink -> sync comment
    (both thanks to Andrew).

v3: Disabled image size check instead of disabling KASAN
    Updated subject to match change
    Updated Cc: list to reflect affected maintainers

v2: Disabled KASAN unconditionally for test builds
    Link: https://lore.kernel.org/lkml/20250416230559.2017012-1-linux@roeck-us.net/

Link to RFC:
    https://lore.kernel.org/lkml/20250414011345.2602656-1-linux@roeck-us.net/

 arch/x86/kernel/vmlinux.lds.S | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index ccdc45e5b759..453f5b5e4817 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -466,10 +466,18 @@ SECTIONS
 }
 
 /*
- * The ASSERT() sink to . is intentional, for binutils 2.14 compatibility:
+ * COMPILE_TEST kernels can be large - CONFIG_KASAN, for example, can cause
+ * this. Let's assume that nobody will be running a COMPILE_TEST kernel and
+ * let's assert that fuller build coverage is more valuable than being able to
+ * run a COMPILE_TEST kernel.
+ */
+#ifndef CONFIG_COMPILE_TEST
+/*
+ * The ASSERT() sync to . is intentional, for binutils 2.14 compatibility:
  */
 . = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
 	   "kernel image bigger than KERNEL_IMAGE_SIZE");
+#endif
 
 /* needed for Clang - see arch/x86/entry/entry.S */
 PROVIDE(__ref_stack_chk_guard = __stack_chk_guard);
-- 
2.45.2

On 4/17/25 05:36, Guenter Roeck wrote:
> Solve the build problem by disabling the image size check for test
> builds.

What _actually_ breaks when this assertion is in play? I assume upon
decompression that the kernel image overflows into the fixmap area and
then the fun begins.

Does anything useful come out of the kernel or is it just a fabulous crash?

Because COMPILE_TEST sounds pretty benign:

>           If you are a developer and want to build everything available, say Y
>           here. If you are a user/distributor, say N here to exclude useless
>           drivers to be distributed.

at the *LEAST* if we are going to go down this road, can we make the
help text more scary and tell users that they might end up with an
unbootable kernel?