From nobody Sat Nov 22 13:48:08 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 4dDD1y3R5Gz6H8xM for ; Sat, 22 Nov 2025 13:48:22 +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 4dDD1x6vbjz3tbg; Sat, 22 Nov 2025 13:48:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none 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 5AMDm82A003285; Sat, 22 Nov 2025 15:48:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AMDm82A003285 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AMDm8eo003284; Sat, 22 Nov 2025 15:48:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 15:48:08 +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> <07201c46-6fb4-4514-aa88-490830edb010@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: <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDD1x6vbjz3tbg On Sat, Nov 22, 2025 at 01:23:00PM +0100, Michal Meloun wrote: > > > On 21.11.2025 21:02, Konstantin Belousov wrote: > > On Fri, Nov 21, 2025 at 09:54:23PM +0200, Konstantin Belousov wrote: > > > On Fri, Nov 21, 2025 at 08:08:47PM +0100, Michal Meloun wrote: > > > > First, many thanks for your efforts, but this check doesn't trigger when the > > > > problem occurs > > > > > > > Hm, ok. This is a data point, in fact. > > > > > > > > > > > To be more precise, testing case > > > > on fresh kernel(d8bfcacd12aba73188c44a157c707908e275825d) > > > > with PMAP_DEBUG defined in pmap-v6.c and with > > > > trivial zero check for first page at this place -> > > > > https://cgit.freebsd.org/src/tree/contrib/jemalloc/src/pages.c#n281 > > > > > > > > causes this failure: > > > > > > > > __je_pages_map: addr: 0x0, ret: 0x3087b000, size: 4096, alignment: 4096, > > > > prot: 0x00000003, flags: 0x0C001002 > > > > __je_pages_map: i: 0, p[i]: 0xFFFFFFFF, p: 0x3087b000 > > > > __je_pages_map: i: 23, p[i]: 0x308E5F94, p: 0x3087b000 > > > > > > Could you, please, when the failure is detected, spawn 'procstat -v ' > > > and dump the memory map of the process? To be clear, I want to see all > > > of this: > > > - the address of the mapping returned by mmap > > > - its size > > > - the location of the first non-zero byte > > > - memory map > > > > Also, regardless of the output above, please try this as a wild guess: > > > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > index 5b4517d2bf0c..5c6ed51706bf 100644 > > --- a/sys/vm/vm_object.c > > +++ b/sys/vm/vm_object.c > > @@ -2222,7 +2222,7 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > * Remove any pages that may still be in the object from a previous > > * deallocation. > > */ > > - if (next_pindex < prev_object->size) { > > + if (true || next_pindex < prev_object->size) { > > vm_object_page_remove(prev_object, next_pindex, next_pindex + > > next_size, 0); > > #if 0 > > > I finally found the right way to obtain both parts of report in synchronized > and straightforward way. > The outputs from procstat -v are in the Outputs from procstat -v are in > attachments, I hope that the mailing list won't eat them. > These are without this patch. > > About this patch - this does not solve the problem, but it measurable > reduces its likelihood. So in both cases you reported below (skipped) the problem indeed appeared in the case where we extend existing mapping, potentially causing the object to reuse the dandling pages after the object' end. This must explain why the debugging patch did not catched anything. It is somewhat strange that the vm_object_coalesce() patch has the non-deterministic effect, but lets see. Below is the big hammer, disabling the extension for the anon mappings at all. Again, I want to know if it helps. This is a debugging aid, not a fix. It should cause large(r) fragmentation of the process map, and possibly much larger kernel memory use, but I hope it is usable for test. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 6b09552c5fee..6a1db58d2d13 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -1732,7 +1732,7 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, vm_object_clear_flag(object, OBJ_ONEMAPPING); VM_OBJECT_WUNLOCK(object); } - } else if ((prev_entry->eflags & ~MAP_ENTRY_USER_WIRED) == + } else if (false && (prev_entry->eflags & ~MAP_ENTRY_USER_WIRED) == protoeflags && (cow & (MAP_STACK_AREA | MAP_VN_EXEC)) == 0 && prev_entry->end == start && (prev_entry->cred == cred ||