From nobody Sat Nov 22 19:54:21 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 4dDN8J1TJhz6HT7r for ; Sat, 22 Nov 2025 19:54:24 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDN8J0nfRz40HZ; Sat, 22 Nov 2025 19:54:24 +0000 (UTC) (envelope-from mmel@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763841264; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vZeF4WJpwiVLdT+/7bQYLoKC6rT7xkVmFOxtRHjqgF0=; b=IULP3Ve/ZFAr42VY9h2issupxYBwXXK6G1R4r5EHDb5dWPDGo0qqIeod85CdUXYMtcgflK p09lldbnni+KtZcwejN6nJ/IKZCNDYXGECiq+vUaE+1MhbKNOGKSI8iUlkTpgDOiOMZ+Hg Pt0fM5RBeCLBayIpt/4yDoAHnJlcmKj4QlxolO+X9y9wt6DnD/4dBCA2UppHCJe+oma1NB fr98j4HG4yeHiuqXzb6BG0TuN6IOYQ5rQoqpn4eM3pcEUvjDei+nGAMvhUVhf/LIizOA3v 4E8YJpZoUxY95uGM1cXYXRojiZiIaPz8wlubFlyY6RKcn3RKaJ5hWrPMpTsteQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763841264; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vZeF4WJpwiVLdT+/7bQYLoKC6rT7xkVmFOxtRHjqgF0=; b=v00A+uggTmwBjwVjfLDSrlUQ1rNrGWEXtGoUWXJMqnezxj8GZyWZ3FkiY9Pw4H4JmzHTAm fuZAGOKdNchI2gxdt8O8V3cuVUOafC2x8MkuGcCz2KRsUwMc7ijyBrDMcLqnfIaZnbRbjT TeLdmOgQNeFOX09+H2L1hNyVmQayLuMPy3okpbyFqSVB+HClhtGZIU/NRZF+4ZMyraxZ6S Q982iXkybTHqprblNaHkMNfb2hlagwtX4lN7SmG7jiHl/mtSmQWuhaxy96wT0mRlTk67Vi ZQs5P68yQUIPpkiFYl3+kEWOh6vtQ5wfHKqa8T8w05URJLnPMCL1Qts/Gav5Yw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763841264; a=rsa-sha256; cv=none; b=Cqv1Ui+JV9uqm0DaFEfMMxYcqKe79UphTX48ox5RfiDlmewcG/mqCZGYYzSp/b/4XBSXz1 WSZ2iIktIDQLBsPlm2oY/wAilvaJS7AjOxUaCWoN1kvHqYmzsNIcvO0brOT9zCSqpQMm+5 fYnFplfRExA2q56m6HhHT5agLpdP2XXD5DVapJzWkosJz78kyumGrHHB7nsUIqzsDm58Mz 8Qt+3ylbv24L/L1lOFbiZMgYal23gA/XiBKIotHCI5qndaTCzf6t3NUcsgI2PxclS+/6dp IE4s+Hpm5SryLqJlGdxsTwVZWQbeMLQ7ShOiBGZbwVroAChNGDsBiP5UznD4Kg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (lety.radiolinkplus.cz [109.205.241.143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dDN8H4lVKzvRM; Sat, 22 Nov 2025 19:54:23 +0000 (UTC) (envelope-from mmel@freebsd.org) Message-ID: <9a864c53-0033-46d1-ad07-6b528115789f@freebsd.org> Date: Sat, 22 Nov 2025 20:54:21 +0100 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 User-Agent: Mozilla Thunderbird From: Michal Meloun Reply-To: mmel@FreeBSD.org Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) To: Konstantin Belousov Cc: FreeBSD Current References: <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22.11.2025 19:45, Konstantin Belousov wrote: > On Sat, Nov 22, 2025 at 07:01:03PM +0100, Michal Meloun wrote: >>> Would you please gather the same ddebugging info, with this patch applied? >> Oups, sorry. >> In meantime, next round with he vm_map patch finished successfully. > > It was still the case of coalescing previous entry and the mapping. > > It is weird, the patch ensures that there is no pages in the object > backing the new region, and due to the ensured properties of the object, > there should be no way to create pages under us. > I am almost sure that the provided patch is correct, but it might be > some additional cases that I miss. > > Please apply the following debugging patch, it includes the vm_object' > part. Instead of allowing the corruption in userspace, kernel should > panic now. Can you confirm that? > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 6b09552c5fee..76808b5ad7f1 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > (vm_size_t)(prev_entry->end - prev_entry->start), > (vm_size_t)(end - prev_entry->end), cred != NULL && > (protoeflags & MAP_ENTRY_NEEDS_COPY) == 0)) { > + vm_object_t obj = prev_entry->object.vm_object; > + if (obj != NULL) { > + struct pctrie_iter pages; > + vm_page_t p; > + > + vm_page_iter_init(&pages, obj); > + p = vm_radix_iter_lookup_ge(&pages, > + OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start)); > + if (p != NULL) { > + KASSERT(p->pindex >= OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start + > + end - start), > + ("FOUND page %p pindex %#jx " > + "e %#jx %#jx %#jx %#jx", > + p, p->pindex, (uintmax_t)prev_entry->offset, > + (uintmax_t)prev_entry->end, > + (uintmax_t)prev_entry->start, > + (uintmax_t)(end - start))); > + } > + } > /* > * We were able to extend the object. Determine if we > * can extend the previous map entry to include the > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..9bb4e54edd96 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > next_size >>= PAGE_SHIFT; > next_pindex = OFF_TO_IDX(prev_offset) + prev_size; > > - if (prev_object->ref_count > 1 && > - prev_object->size != next_pindex && > + if (prev_object->ref_count > 1 || > + prev_object->size != next_pindex || > (prev_object->flags & OBJ_ONEMAPPING) == 0) { > VM_OBJECT_WUNLOCK(prev_object); > return (FALSE); > } > > + KASSERT(next_pindex + next_size > prev_object->size, > + ("vm_object_coalesce: " > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > + (uintmax_t)prev_object->size)); > + > /* > * Account for the charge. > */ > @@ -2222,26 +2228,13 @@ 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) { > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > - next_size, 0); > -#if 0 > - if (prev_object->cred != NULL) { > - KASSERT(prev_object->charge >= > - ptoa(prev_object->size - next_pindex), > - ("object %p overcharged 1 %jx %jx", prev_object, > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > - prev_object->charge -= ptoa(prev_object->size - > - next_pindex); > - } > -#endif > - } > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > + next_size, 0); > > /* > * Extend the object if necessary. > */ > - if (next_pindex + next_size > prev_object->size) > - prev_object->size = next_pindex + next_size; > + prev_object->size = next_pindex + next_size; > > VM_OBJECT_WUNLOCK(prev_object); > return (TRUE); Unfortunately, KASSERT doesn't assert on failure. Don't hit me, please. :) Could this be related to the fact that the VMA has another region immediately after added page? __je_pages_map: addr: 0x0, ret: 0x34f6f000, size: 4096, alignment: 4096, prot: 0x00000003, flags: 0x0C001002 __je_pages_map: i: 0, p[i]: 0xFFFFF000, p: 0x34f6f000 ... _3440 0x34f4e000 0x34f6e000 rw- 0 3 13 0 ----- sw 3440 0x34f6e000 0x34f70000 rw- 1 1 1 0 ----- sw 3440 0x34f70000 0x34f82000 rw- 0 3 13 0 ----- sw ...