From nobody Fri Nov 21 09:03:44 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dCTmF40cxz6GsTN for ; Fri, 21 Nov 2025 09:03:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCTmD4tpMz45QZ; Fri, 21 Nov 2025 09:03:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AL93iVJ016155; Fri, 21 Nov 2025 11:03:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AL93iVJ016155 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AL93igT016154; Fri, 21 Nov 2025 11:03:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Nov 2025 11:03:44 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: / X-Spamd-Result: default: False [-0.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_MEDIUM(1.00)[0.997]; NEURAL_HAM_SHORT(-0.73)[-0.732]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4dCTmD4tpMz45QZ On Fri, Nov 21, 2025 at 10:36:42AM +0200, Konstantin Belousov wrote: > On Fri, Nov 21, 2025 at 08:12:55AM +0100, Michal Meloun wrote: > > I have confirmed that jmalloc assertions are caused by mmap() failure. It > > can return non-zeroed page(s) for mmap(MAP_ANON), which is clearly a bug. > > > > I have confirmed this on native ARMv7, and according to Mark, it is also > > reproducible on ARM32 and i386 jails. I think I saw it also on a > > memory-constrained (4 GB) aarch64, but I cannot reproduce it yet. > > > > Have somebody idea how to identify vm faults associated with anon mmap to > > trigger detection of this failure in kernel? Or any other hint? > > I think It would be much more visible if freshly allocated anonymous pages > are corrupted. A similar mechanism to get zeroed pages is used to get > fresh page table pages, and corruption there must cause a lot of kernel > page faults with 'invalid PTE bit' hw reports. > But of course everything is possible. > > VM has an optimization where we track known-to-be-zeroed free page > separately, by marking them with PG_ZERO flag. If allocation needs a > zeroed page and the flag is set, we skip calling pmap_zero_page() on it. > > Also, in vm_page_free_prep() when we are told that the page is zeroed, > with DIAGNOSTIC enabled, on amd64 and arm64, we do check for that. > > So lets add slow check for vm_fault code that supposedly zeroed page is > indeed zeroed. Can you try to catch the issue with the patch applied, > and DIAGNOSTIC enabled? Patch is arch-agnostic and I believe should > work on armv7, although obviously causing slowdown. I also made the vm_page_free_prep() check MI. Please use https://reviews.freebsd.org/D53850 instead of the previous patch.