From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D23894C6C for ; Mon, 17 Nov 2025 14:08:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763388506; cv=none; b=OJp3NlRv8hCPzxpHjRtbDs607IglVHrltz5W0Jz1HP7C4ClhFjGO4FUiYtQGuZooWqbL1A3NdohN+NDupoPWMdUlcyZlqPTO2TSNmO0yub3i9+SJ2xygaHimQSQ32UBr/norA64zJ2M5e8zL8gwOi5vo2c6zqz1C010s5DPWHVE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763388506; c=relaxed/simple; bh=msr1y06jM8iHCODJGd4GT9ZAdIjidows4UbTbNaiNpI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gP2jpVI+V/CMT09m1Nmr6fSsa3lNbi7ONQInWSOeInLYmf8h36eF5jP262R5cO8TnCyRGsKN4ST2+JdjUw0ckBFW6XLXOkwARbVr+keyIzzfVEyUym2kUbPwIErrjsFFRyUvr5SA2CJ3/PfVPfNCWWQuO2W9wRWjDmundNpy4Tc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IoFslwci; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IoFslwci" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98ED5C4CEF1; Mon, 17 Nov 2025 14:08:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763388506; bh=msr1y06jM8iHCODJGd4GT9ZAdIjidows4UbTbNaiNpI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=IoFslwciJ8lAMXI06VG91U+I0DJNnPuQGot0WYeJz3exaIYwfHJ2/zlUbsLm0g3yH rv/MUJY3+BmSJZnR7YG9QtE/VnMOOavqq2W+TfG3vaocgi/mqtKTbKHBFLJt1s52vo LQF8ImoO5SvTp3wsR0p2czsK08Xg7uK0d8OJlVblpLDkcEwpoMXC0Cipgp+3ZzKBvk Knrop9yakzB77b4PSvdSU0l28lynBgkmeYxDpy4v38BL6pR6lGX0/8rdduqa85QeJl FpYbC9w7G3LQGSr5i4ssfe9/wT2maK14rHpHuZj13+lnGLp7i6+8ax8dfdLQyyGwNg Abg3yG/xQL/Nw== Message-ID: <25e4c75c-097d-44bb-8739-136a0238d5bf@kernel.org> Date: Mon, 17 Nov 2025 15:08:22 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Linux 6.18-rc6 To: David Wang <00107082@163.com> Cc: Linus Torvalds , catalin.marinas@arm.com, lance.yang@linux.dev, b-padhi@ti.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Jan Polensky References: <20251117082023.90176-1-00107082@163.com> <6c09aaea.aa4a.19a91e379ab.Coremail.00107082@163.com> <37bad560-a8f3-4ae2-aa34-1edc635062c0@kernel.org> <1c14c47e.ab83.19a92102b26.Coremail.00107082@163.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <1c14c47e.ab83.19a92102b26.Coremail.00107082@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 17.11.25 14:45, David Wang wrote: > > > At 2025-11-17 21:30:42, "David Hildenbrand (Red Hat)" wrote: >> On 17.11.25 13:56, David Wang wrote: >>> >>> At 2025-11-17 18:33:58, "Linus Torvalds" wrote: >>>> On Mon, 17 Nov 2025 at 00:20, David Wang <00107082@163.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 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)" 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 Closes: https://lore.kernel.org/r/20251109003613.1461433-1-japo@linux.ibm.com Reported-by: David Wang <00107082@163.com> Closes: https://lore.kernel.org/r/6c09aaea.aa4a.19a91e379ab.Coremail.00107082@163.com Debugged-by: Jan Polensky Fixes: 1579227fe0f0 ("mm/huge_memory: initialise the tags of the huge zero folio") Signed-off-by: David Hildenbrand (Red Hat) --- 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