[PATCH] [RFC] ubsan: turn off UBSAN_ALIGNMENT on s390

[Arnd Bergmann]

From: Arnd Bergmann <ar...@arndb.de>

Testing randconfig builds on s390 with gcc-15, I came across a number of
seemingly unrelated build failures that ended up all being caused
by the -fsanitize=alignment option:

s390-linux-ld: kernel/sched/build_policy.o: in function `thread_group_cputime':
include/linux/seqlock.h:1286:(.text+0x1f738): undefined reference to `__scoped_seqlock_bug'

lib/tests/overflow_kunit.c: In function 'same_type_test':
lib/tests/overflow_kunit.c:1008:13: note: variable tracking size limit exceeded with '-fvar-tracking-assignments', retrying without

fs/fat/fat_test.c: In function 'fat_clus_to_blknr_test':
fs/fat/fat_test.c:33:1: error: the frame size of 4736 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
lib/crypto/chacha-block-generic.c: In function 'chacha_permute':
lib/crypto/chacha-block-generic.c:65:1: error: the frame size of 2000 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
lib/crypto/sha3.c: In function 'sha3_keccakf_generic':
lib/crypto/sha3.c:175:1: error: the frame size of 2248 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
lib/zstd/decompress/huf_decompress.c: In function 'HUF_decompress4X2_usingDTable_internal_default':
lib/zstd/decompress/huf_decompress.c:1512:1: error: the frame size of 1352 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]

What I observe here is a huge increase in generated calls to
__ubsan_handle_type_mismatch_v1() that ends up thowing off a number of
compiler optimizations that the kernel relies on.

I have not been able to figure out why this happens on s390 but not arm64,
arm or x86, if other toolchain versions are affected by the same thing,
and if this is a problem in gcc or in the kernel itself, e.g. some
variable being identified as unaligned when it should be aligned.

This clearly needs more investigation to figure out properly what is
going on, but turning it off is currently required for randconfig testing.

Cc: Kees Cook <ke...@kernel.org>
Cc: Marco Elver <el...@google.com>
Cc: Andrey Konovalov <andre...@gmail.com>
Cc: Andrey Ryabinin <ryabin...@gmail.com>
Cc: kasa...@googlegroups.com
Cc: linux-h...@vger.kernel.org
Cc: Heiko Carstens <h...@linux.ibm.com>
Cc: Vasily Gorbik <g...@linux.ibm.com>
Cc: Alexander Gordeev <agor...@linux.ibm.com>
Cc: Christian Borntraeger <bornt...@linux.ibm.com>
Cc: Sven Schnelle <sv...@linux.ibm.com>
Cc: linux...@vger.kernel.org
Signed-off-by: Arnd Bergmann <ar...@arndb.de>
---
lib/Kconfig.ubsan | 1 +
1 file changed, 1 insertion(+)

diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 1ecaae7064d2..3fc03a6b5af4 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -152,6 +152,7 @@ config UBSAN_ENUM

config UBSAN_ALIGNMENT
bool "Perform checking for misaligned pointer usage"
+ depends on !S390 || BROKEN
default !HAVE_EFFICIENT_UNALIGNED_ACCESS
depends on !UBSAN_TRAP && !COMPILE_TEST
depends on $(cc-option,-fsanitize=alignment)
--
2.39.5

[Heiko Carstens]

On Fri, May 15, 2026 at 11:19:54AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <ar...@arndb.de>
>
> Testing randconfig builds on s390 with gcc-15, I came across a number of
> seemingly unrelated build failures that ended up all being caused
> by the -fsanitize=alignment option:
>
> s390-linux-ld: kernel/sched/build_policy.o: in function `thread_group_cputime':
> include/linux/seqlock.h:1286:(.text+0x1f738): undefined reference to `__scoped_seqlock_bug'

Does this only happen with __scoped_seqlock_bug()?
I just enabled UBSAN_ALIGNMENT, and with gcc-16 I can see this too.

> What I observe here is a huge increase in generated calls to
> __ubsan_handle_type_mismatch_v1() that ends up thowing off a number of
> compiler optimizations that the kernel relies on.
>
> I have not been able to figure out why this happens on s390 but not arm64,
> arm or x86, if other toolchain versions are affected by the same thing,
> and if this is a problem in gcc or in the kernel itself, e.g. some
> variable being identified as unaligned when it should be aligned.
>
> This clearly needs more investigation to figure out properly what is
> going on, but turning it off is currently required for randconfig testing.

...

> ---
> lib/Kconfig.ubsan | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index 1ecaae7064d2..3fc03a6b5af4 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -152,6 +152,7 @@ config UBSAN_ENUM
>
> config UBSAN_ALIGNMENT
> bool "Perform checking for misaligned pointer usage"
> + depends on !S390 || BROKEN

Wouldn't it be more appropriate to extend the ifdef at __scoped_seqlock_bug()
which emits an empty function for exactly this reason for some gcc versions
and kernel configs?

That is: add CONFIG_UBSAN_ALIGNMENT to the list (copy-pasted - white space
damage below)?

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 5a40252b8334..18affa4d21a6 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -1259,7 +1259,7 @@ static __always_inline void __scoped_seqlock_cleanup(struct ss_tmp *sst)

extern void __scoped_seqlock_invalid_target(void);

-#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) || defined(CONFIG_KASAN)
+#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) || defined(CONFIG_KASAN) || defined(CONFIG_UBSAN_ALIGNMENT)
/*
* For some reason some GCC-8 architectures (nios2, alpha) have trouble
* determining that the ss_done state is impossible in __scoped_seqlock_next()

[Arnd Bergmann]

On Fri, May 15, 2026, at 18:53, Heiko Carstens wrote:
> On Fri, May 15, 2026 at 11:19:54AM +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann <ar...@arndb.de>
>>
>> Testing randconfig builds on s390 with gcc-15, I came across a number of
>> seemingly unrelated build failures that ended up all being caused
>> by the -fsanitize=alignment option:
>>
>> s390-linux-ld: kernel/sched/build_policy.o: in function `thread_group_cputime':
>> include/linux/seqlock.h:1286:(.text+0x1f738): undefined reference to `__scoped_seqlock_bug'
>
> Does this only happen with __scoped_seqlock_bug()?
> I just enabled UBSAN_ALIGNMENT, and with gcc-16 I can see this too.

Yes, it's specifically this one file that triggers the
__scoped_seqlock_bug check.

>> --- a/lib/Kconfig.ubsan
>> +++ b/lib/Kconfig.ubsan
>> @@ -152,6 +152,7 @@ config UBSAN_ENUM
>>
>> config UBSAN_ALIGNMENT
>> bool "Perform checking for misaligned pointer usage"
>> + depends on !S390 || BROKEN
>
> Wouldn't it be more appropriate to extend the ifdef at __scoped_seqlock_bug()
> which emits an empty function for exactly this reason for some gcc versions
> and kernel configs?
>
> That is: add CONFIG_UBSAN_ALIGNMENT to the list (copy-pasted - white space
> damage below)?

This would work around the failed check in kernel/sched/build_policy.o
but not address the underlying issue, or any other the other symptoms.

After trying to come up with a simplified test case that shows
a problem on s390 but not arm64, I have now realized what is going
on: My randconfig build script force-enables 'CONFIG_COMPILE_TEST=y'
on all architectures, in order to avoid known-broken configurations
and options that lead to a longer build time but are unlikely
to find additional bugs. UBSAN_ALIGNMENT in turn depends on
!COMPILE_TEST as of d0a3ac549f38 ("ubsan: enable for all*config
builds"). On s390, COMPILE_TEST is unavailable when MMIO is
disabled, so randconfig builds sometimes run into those broken
configurations on s390 that I don't see elsewhere.

I think your suggestion for __scoped_seqlock_bug makes sense,
and I've sent a fix for the fs/fat/ issue. I'll see if I can
also reproduce the other issues across architectures and come
up with local workarounds for UBSAN_ALIGNMENT.

Arnd

[Peter Zijlstra]

Right, so I have a GCC bug and some mail with Kees about all of this.

I wanted to add: CONFIG_UBSAN

But for 'raisins' the whole bounds checking thing is mangled into UBSAN,
so everybody + dog has UBSAN on in their .config :/

IIRC Kees was going to look at untangling bounds checking from UBSAN and
make UBSAN pure debugging stuff (again). But I don't think he's managed
to find time for this.

Anyway, yes, I suppose we can do as proposed.