| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <25e4c75c-097d-44bb-8739-136a0238d5bf@kernel.org>
Date: Mon, 17 Nov 2025 15:08:22 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: David Wang <00107082@....com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, catalin.marinas@....com,
lance.yang@...ux.dev, b-padhi@...com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, Jan Polensky <japo@...ux.ibm.com>
Subject: Re: Linux 6.18-rc6
On 17.11.25 14:45, David Wang wrote:
>
>
> At 2025-11-17 21:30:42, "David Hildenbrand (Red Hat)" <david@...nel.org> wrote:
>> On 17.11.25 13:56, David Wang wrote:
>>>
>>> At 2025-11-17 18:33:58, "Linus Torvalds" <torvalds@...ux-foundation.org> wrote:
>>>> On Mon, 17 Nov 2025 at 00:20, David Wang <00107082@....com> wrote:
>>>>>
>>>>> After upgrade to 6.18-rc6, all my golang programs start to crash, even Go compiler crashes;
>>>>> and when I started bisect, `make vmlinux` crashes too.
>>>>
>>>> Funky funky. Certainly doesn't happen here.
>>>>
>>>>> I am running bisect with 6.18-rc5 now, any chance this has already caught/fixed?
>>>>
>>>> Please do run the bisect (obviously you'll have to build using a
>>>> kernel that works for you), I am not aware of anybody reporting
>>>> anything like this.
>>>
>>> Hi,
>>>
>>> Bisect narrowed it down to
>>> [adfb6609c6809e107ded9a1cd46f519c882e64ea] mm/huge_memory: initialise the tags of the huge zero folio
>>>
>>> It seems happen to program build with older version of go, mine is 1.18.4; and I cannot reproduce it with go1.25.4.
>>>
>>> When I upgraded to 6.18-rc6, go1.18.4 compiler/program would crash with,
>>>
>>> fatal error: arena already initialized
>>>
>>> runtime stack:
>>> runtime.throw({0x9ea9fe?, 0x0?})
>>> /usr/local/go/src/runtime/panic.go:992 +0x71 fp=0x7ffdf458a248 sp=0x7ffdf458a218 pc=0x435ab1
>>> runtime.(*mheap).sysAlloc(0xddec20, 0x0?)
>>> /usr/local/go/src/runtime/malloc.go:749 +0x2e9 fp=0x7ffdf458a2e0 sp=0x7ffdf458a248 pc=0x40dee9
>>> ...
>>>
>>>
>>> And when I `make vmlinux`, I got something like this :
>>> AR vmlinux.a
>>> LD vmlinux.o
>>> GEN .vmlinux.objs
>>> MODPOST vmlinux.symvers
>>> CC .vmlinux.export.o
>>> UPD include/generated/utsversion.h
>>> CC init/version-timestamp.o
>>> KSYMS .tmp_vmlinux0.kallsyms.S
>>> AS .tmp_vmlinux0.kallsyms.o
>>> LD .tmp_vmlinux1
>>> NM .tmp_vmlinux1.syms
>>> KSYMS .tmp_vmlinux1.kallsyms.S
>>> AS .tmp_vmlinux1.kallsyms.o
>>> .tmp_vmlinux1.kallsyms.S:361542:19: internal compiler error: Aborted
>>> 361542 | .byte 0x00, 0x99, 0xe9 /* T__pfx___x64_sys_inotify_add_watch */
>>> | ^
>>> 0x7f983a551def ???
>>> ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
>>> 0x7f983a5a695c __pthread_kill_implementation
>>> ./nptl/pthread_kill.c:44
>>> 0x7f983a551cc1 __GI_raise
>>> ../sysdeps/posix/raise.c:26
>>> 0x7f983a53a4ab __GI_abort
>>> ./stdlib/abort.c:73
>>> 0x7f983a53bca7 __libc_start_call_main
>>> ../sysdeps/nptl/libc_start_call_main.h:58
>>> 0x7f983a53bd64 __libc_start_main_impl
>>> ../csu/libc-start.c:360
>>> Please submit a full bug report, with preprocessed source (by using -freport-bug).
>>> Please include the complete backtrace with any bug report.
>>> See <file:///usr/share/doc/gcc-14/README.Bugs> for instructions.
>>> make[2]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
>>> make[1]: *** [/home/linan/codes/linux-kernel/linux/Makefile:1242: vmlinux] Error 2
>>> make: *** [Makefile:248: __sub-make] Error 2
>>> $ gcc --version
>>> gcc (Debian 14.2.0-19) 14.2.0
>>>
>>> (It dose not always happens, sometimes I don't get this crash and It dose not always err on same line.)
>>>
>>> And nothing abnormal shows up in kernel message.
>>>
>>> Revert adfb6609c6809e107ded9a1cd46f519c882e64ea can fix my crashing go programs.
>>
>>
>> I just replied privately to a similar report the following:
>>
>> Hi,
>>
>> I observed something similar while testing on Friday between rc4 (good)
>> and rc5+ (bad).
>>
>>
>> I'm sure this it the known issue of
>> adfb6609c6809e107ded9a1cd46f519c882e64ea we discussed already here [1].
>>
>>
>> @Jan, can you send the fix out today? Otherwise I can take care of this
>> so we get this fixed asap.
>>
>> [1] https://lkml.kernel.org/r/20251109003613.1461433-1-japo@linux.ibm.com
>>
>>
>> --
>> Cheers
>>
>> David
>
> Good to know~
>
> My system is AMD, I would be glad to test the patch when it is ready.
To not lose too much time, I just pushed the following patch to
https://github.com/davidhildenbrand/linux.git zerotags
It would be great if you could give that a spin, I'm still
cross-compiling it on a bunch of targets.
From 58e62699f77738188730d489accd01ad8e3cdeeb Mon Sep 17 00:00:00 2001
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
Date: Mon, 17 Nov 2025 14:49:35 +0100
Subject: [PATCH] mm/huge_memory: fix __GFP_ZEROTAGS on architectures without
memory tags
Unfortunately, __GFP_ZEROTAGS is not properly ignored on architectures
without memory tags (i.e., on all architectures except arm64), and
ends up calling an empty stub tag_clear_highpage().
Common code in post_alloc_hook() assumes that when we call
tag_clear_highpage(), that both the tags and the memory were clear --
to then skip actual clearing of the memory.
So ever since we started allocating the huge zero folio with __GFP_ZEROTAGS
that implies that we will not be clearing out the content of the huge
zero folio.
Fix it by properly ignoring __GFP_ZEROTAGS if there is no architecture
support, so we compile out the handling in the page allocator code
completely and just zero these pages ordinarily.
Make the default tag_clear_highpage() BUILD_BUG() and guard it by
a new Kconfig option.
Thanks to Jan Polensky for debugging the issue and sending an initial fix.
Reported-by: Jan Polensky <japo@...ux.ibm.com>
Closes: https://lore.kernel.org/r/20251109003613.1461433-1-japo@linux.ibm.com
Reported-by: David Wang <00107082@....com>
Closes: https://lore.kernel.org/r/6c09aaea.aa4a.19a91e379ab.Coremail.00107082@163.com
Debugged-by: Jan Polensky <japo@...ux.ibm.com>
Fixes: 1579227fe0f0 ("mm/huge_memory: initialise the tags of the huge zero folio")
Signed-off-by: David Hildenbrand (Red Hat) <david@...nel.org>
---
arch/Kconfig | 4 ++++
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/page.h | 1 -
include/linux/gfp_types.h | 6 ++++++
include/linux/highmem.h | 3 ++-
include/trace/events/mmflags.h | 9 ++++++++-
6 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 61130b88964b9..37a3d0b72fab1 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -348,6 +348,10 @@ config ARCH_HAS_SET_MEMORY
config ARCH_HAS_SET_DIRECT_MAP
bool
+# Select if memory tags (e.g., GFP_ZEROTAGS) are supported
+config ARCH_HAS_MEMORY_TAGS
+ bool
+
#
# Select if the architecture provides the arch_dma_set_uncached symbol to
# either provide an uncached segment alias for a DMA allocation, or
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6663ffd23f252..dea73ff9291d6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -35,6 +35,7 @@ config ARM64
select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_MEMBARRIER_SYNC_CORE
+ select ARCH_HAS_MEMORY_TAGS
select ARCH_HAS_MEM_ENCRYPT
select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 2312e6ee595fd..52ecb524af344 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -34,7 +34,6 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
#define vma_alloc_zeroed_movable_folio vma_alloc_zeroed_movable_folio
void tag_clear_highpage(struct page *to);
-#define __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
#define clear_user_page(page, vaddr, pg) clear_page(page)
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 65db9349f9053..9f75c4b5ab2d7 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -47,7 +47,9 @@ enum {
___GFP_HARDWALL_BIT,
___GFP_THISNODE_BIT,
___GFP_ACCOUNT_BIT,
+#ifdef CONFIG_ARCH_HAS_MEMORY_TAGS
___GFP_ZEROTAGS_BIT,
+#endif
#ifdef CONFIG_KASAN_HW_TAGS
___GFP_SKIP_ZERO_BIT,
___GFP_SKIP_KASAN_BIT,
@@ -85,7 +87,11 @@ enum {
#define ___GFP_HARDWALL BIT(___GFP_HARDWALL_BIT)
#define ___GFP_THISNODE BIT(___GFP_THISNODE_BIT)
#define ___GFP_ACCOUNT BIT(___GFP_ACCOUNT_BIT)
+#ifdef CONFIG_ARCH_HAS_MEMORY_TAGS
#define ___GFP_ZEROTAGS BIT(___GFP_ZEROTAGS_BIT)
+#else
+#define ___GFP_ZEROTAGS 0
+#endif
#ifdef CONFIG_KASAN_HW_TAGS
#define ___GFP_SKIP_ZERO BIT(___GFP_SKIP_ZERO_BIT)
#define ___GFP_SKIP_KASAN BIT(___GFP_SKIP_KASAN_BIT)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 105cc4c00cc34..f3eaa605d68c1 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -249,10 +249,11 @@ static inline void clear_highpage_kasan_tagged(struct page *page)
kunmap_local(kaddr);
}
-#ifndef __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
+#ifndef CONFIG_ARCH_HAS_MEMORY_TAGS
static inline void tag_clear_highpage(struct page *page)
{
+ BUILD_BUG();
}
#endif
diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
index aa441f593e9a6..c8436c2f428d7 100644
--- a/include/trace/events/mmflags.h
+++ b/include/trace/events/mmflags.h
@@ -36,8 +36,14 @@
TRACE_GFP_EM(NOMEMALLOC) \
TRACE_GFP_EM(HARDWALL) \
TRACE_GFP_EM(THISNODE) \
- TRACE_GFP_EM(ACCOUNT) \
+ TRACE_GFP_EM(ACCOUNT)
+
+#ifdef CONFIG_ARCH_HAS_MEMORY_TAGS
+# define TRACE_GFP_FLAGS_TAGS \
TRACE_GFP_EM(ZEROTAGS)
+#else
+# define TRACE_GFP_FLAGS_TAGS
+#endif
#ifdef CONFIG_KASAN_HW_TAGS
# define TRACE_GFP_FLAGS_KASAN \
@@ -63,6 +69,7 @@
#define TRACE_GFP_FLAGS \
TRACE_GFP_FLAGS_GENERAL \
+ TRACE_GFP_FLAGS_TAGS \
TRACE_GFP_FLAGS_KASAN \
TRACE_GFP_FLAGS_LOCKDEP \
TRACE_GFP_FLAGS_SLAB
--
2.51.0
--
Cheers
David
Powered by blists - more mailing lists