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 F010E331A69 for ; Tue, 18 Nov 2025 14:12:12 +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=1763475134; cv=none; b=bxlpL+zC75NXYU/KTjXtkDjJYqHJ0aeOwG71iIdTUdxUjB4QJrusYJWeIzeKw0aPYbqUmNqn4M9O61u/zVCuGrMBSsK8/RZeIaPnf7A2aaHtlqs3EBbJCkk/UGveHVf/9w+uemC0LsQtaRexEXjAxRHdGF4QeBidgRmXQ4Cixlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763475134; c=relaxed/simple; bh=ucvfqT/87AIJX/kBv7Hg0i2D3ninb/s0jZPpeQH3TbE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=e/lfl2PbHd5s0If8vYX+k4JmG3Dnxl/5lHFLOHInAEBb5huHTpiVkU3/wuwYdm8t1a2/yyIktprBKdGTXRpxAj0xJXFg8Xb+etuB44+9R5jdBMg4rZBBNCpMV9rd7ThtxSPigMxAhkgHIfFPJL9KCULqCG6D/2njyv67qlJUAKw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=otx176RH; 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="otx176RH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97732C4CEF1; Tue, 18 Nov 2025 14:12:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763475132; bh=ucvfqT/87AIJX/kBv7Hg0i2D3ninb/s0jZPpeQH3TbE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=otx176RHXk95tTa5jPS/siFig5zrBaRR2XgEMtj95+TDolqvxpOSNif80LVMKq7yp yweWDKJgqRt5yOINITtbWI88pCGNMj7seJ8icQ9ySIYXNrCCD14O4BfbUDDrKJps7w Ed1cEToWpSsrJHuHPlUsCTpl5iK02FZNWpaCbF9DIVLgjeKJuk6/3b89kfDR7u08HN U0syNf8Ho3etekNU5agQ0VU+K09URIFoYuDgGHhOBgTarccvIhrnCUFiUCdI/w/7Xe NXkYLSUeXdjZIJSgewdR/rwAlfk4dQXcAikAoBmLbI2fnzsY2kv32/3iSyXyISXwMl z5l3MyqY3DE6g== Message-ID: Date: Tue, 18 Nov 2025 15:12:08 +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>, Linus Torvalds Cc: 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> <25e4c75c-097d-44bb-8739-136a0238d5bf@kernel.org> <189cfb08-2593-4ff1-a3fa-3c7957cb6b60@kernel.org> <08790cc2-0db4-4920-8331-9061114e8645@kernel.org> <5903ee6c-3774-47d6-b14a-51201fd75c0f@kernel.org> <1b2ab63f.a8c2.19a974009bc.Coremail.00107082@163.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <1b2ab63f.a8c2.19a974009bc.Coremail.00107082@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 18.11.25 14:55, David Wang wrote: > > > At 2025-11-18 12:13:15, "David Wang" <00107082@163.com> wrote: >> >> >> At 2025-11-18 09:10:50, "Linus Torvalds" wrote: >>> On Mon, 17 Nov 2025 at 11:17, David Hildenbrand (Red Hat) >>> wrote: >>>> >>>> So, I briefly tried on x86 with KASAN and the one-liner. I was assuming >>>> that KASAN would complain because we are clearing the page before doing >>>> the kasan_unpoison_pages() (IOW, writing to a KASAN-poisoned page). >>>> >>>> It didn't trigger, and I assume it is because clear_highpage() on x86 >>>> will not be instrumented by KASAN (my theory). >>>> >>>> The comment in kernel_init_pages() indicates that s390x uses memset() >>>> for that purpose and I would assume that that one would be instrumented. >>> >>> So I have thought about this some more, and I am not entirely happy >>> about any of this, but I think the way forward is to >>> >>> (a) make tag_clear_highpage() just do multiple pages in one go (and >>> rename it as tag_clear_highpage*s*() in the process) >>> >>> (b) make it have an actually return value to indicate whether it >>> initialized things >>> >>> which means that the post_alloc_hook() code just becomes >>> >>> if (zero_tags) >>> init = tag_clear_highpages(page, 1 << order); >>> >>> and then the generic fallback becomes just >>> >>> static inline bool tag_clear_highpages(struct page *page, int numpages) >>> { >>> return false; >>> } >>> >>> which makes this all a complete no-op for architectures that don't do >>> this memory tagging. >>> >>> And the one architecture that *does* do it - arm64 - actually >>> simplifies too, because now instead of being called in a loop - and >>> having that >>> >>> if (!system_supports_mte()) { >>> clear_highpage(page); >>> return; >>> } >>> >>> in every iteration of the loop, it now just gets called *once*, and it >>> instead just does >>> >>> if (!system_supports_mte()) >>> return false; >>> >>> and then it does the *clearing* in a loop instead. >>> >>> End result: that all looks much saner to me, and should avoid all the >>> issues with KASAN (well, arm64 currently clearly depends on >>> mte_zero_clear_page_tags() being assembly code that doesn't trigger >>> KASAN anyway). >>> >>> But maybe it looks saner to me just because I've written that code now. >>> >>> Anyway, here's my suggested patch. I still prefer this over having >>> more config variables and #ifdef's. I'd much rather have code that >>> just does the right thing and becomes null and void when it's >>> effecitlvely disabled by not having hardware support. >>> >>> Comments? >>> >>> This is all entirely untested, but I did build it on both x86-64 and >> >>> arm64. So it must be perfect. Right? >> >> >> I tried this patch, my prometheus service crash with: >> fatal error: acquireSudog: found s.elem != nil in cache >> seems some memory is still not properly zeroed. (I guess) >> But this time, my old go compiler works fine. > > > Update: with this patch, my go programs still crash, It was just that > the first time I test the patch, old go compiler happened to work. When I reboot, my > go program start to crash again. The crash seems random, but on my system, > go program crashes with *very* high probability. > > (And I applied the patch based on 6.18-rc6.) Can you try with init = !tag_clear_highpages(page, 1 << order); instead of init = tag_clear_highpages(page, 1 << order); So when the function returns "false" (we did not clear), we will have to initialize. -- Cheers David