Date: Sat, 22 Nov 2025 18:44:36 -0800 From: Mark Millard <marklmi@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com>, meloun.michal@gmail.com, FreeBSD Current <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com> Cc: bob prohaska <fbsd@www.zefox.net>, Adrian Chadd <adrian@freebsd.org>, Carl Shapiro <cshapiro@panix.com>, Ronald Klop <ronald@freebsd.org>, "Herbert J. Skuhra" <herbert@gojira.at> Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) [*** latest test patch update working in i386 and armv7 chroot tests ***] Message-ID: <3D910723-3325-425A-9E72-2F6DE99D1067@yahoo.com> In-Reply-To: <48467E94-9A3E-4287-998D-EC9360337275@yahoo.com> References: <75CEABED-3CCB-4DB9-AC82-5980696C2A06@yahoo.com> <48467E94-9A3E-4287-998D-EC9360337275@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 22, 2025, at 13:55, Mark Millard <marklmi@yahoo.com> wrote:
> Konstantin Belousov <kostikbel_at_gmail.com> w rote on
> Date: Sat, 22 Nov 2025 20:41:27 UTC :
>
>> On Sat, Nov 22, 2025 at 10:19:38PM +0200, Konstantin Belousov wrote:
>>> Please in addition to the patch, enable debug.vm_check_pg_zero.
>>
>> And use the following patch (one more hunk for vm_object_page_remove()):
>>
>> 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..e87047f9a380 100644
>> --- a/sys/vm/vm_object.c
>> +++ b/sys/vm/vm_object.c
>> @@ -1988,7 +1988,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t start, vm_pindex_t end,
>> (options & (OBJPR_CLEANONLY | OBJPR_NOTMAPPED)) == OBJPR_NOTMAPPED,
>> ("vm_object_page_remove: illegal options for object %p", object));
>> if (object->resident_page_count == 0)
>> - return;
>> + goto remove_pager;
>> vm_object_pip_add(object, 1);
>> vm_page_iter_limit_init(&pages, object, end);
>> again:
>> @@ -2061,6 +2061,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t start, vm_pindex_t end,
>> }
>> vm_object_pip_wakeup(object);
>>
>> +remove_pager:
>> vm_pager_freespace(object, start, (end == 0 ? object->size : end) -
>> start);
>> }
>> @@ -2189,13 +2190,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 +2229,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);
[The Email handling did not preserve much of the whitespace
in the above diff.]
> This completed the lib/clang/libllvm /and lib/clang/libclang/
> build activity from prior partial runs. So I started
> buildworld over after doing the "rm -fr". It has completed
> past the :
>
> /usr/obj/usr/src/i386.i386/lib/clang/
>
> part of the buildworld and is continuing.
>
> So far so good.
>
>
> Is 15.0 going to hold off for the final form of this? Get
> an EN later?
The i386 chroot on amd64 boot-system test finished just fine:
--------------------------------------------------------------
>>> World build completed on Sat Nov 22 21:58:09 UTC 2025
>>> World built in 2330 seconds, ncpu: 32, make -j10
--------------------------------------------------------------
As did the armv7 chroot on aarch64 boot-system test:
--------------------------------------------------------------
>>> World build completed on Sat Nov 22 17:55:38 PST 2025
>>> World built in 11501 seconds, ncpu: 8, make -j8
--------------------------------------------------------------
(The -jN numbers combined with the RAM+SWAP figures achieved
for each made for useful tests of the original problem.)
Prior to the changes, each of those had to be restarted a
bunch of times to finish the libprivatellvm.so.19 and
libprivateclang.so.19 parts of the overall build.
The above tests were both made after the new assignment:
# sysctl debug.vm_check_pg_zero=1
debug.vm_check_pg_zero: 0 -> 1
that enables some new, expensive INVARIANTS code.
Note that the code for testing is not claimed to be the
actual fix that will be used. It was for information
gathering.
As I understand things, the changes involved apply to all
supported FreeBSD platforms, not just 32-bit i386 and armv7.
It seems jemalloc 5.3.0 used the FreeBSD kernel somewhat
differently and ran into a long standing problem: what it
was doing should have been valid. None of the investigative
update was to the jemalloc code.
But it could be that, on review, tradeoff management could
involve jemalloc code for all I know.
As stands:
/usr/src/sys/vm/vm_extern.h.orig
/usr/src/sys/vm/vm_fault.c.orig
/usr/src/sys/vm/vm_map.c.orig
/usr/src/sys/vm/vm_object.c.orig
/usr/src/sys/vm/vm_page.c.orig
were created so that I could use them to restore my
official pkgbase source (that is somewhat older).
Side note:
I've not sent this note to mmel at freebsd.org as it forwards
to meloun.michal at gmail.com and:
QUOTE
Gmail has detected that this message
550-5.7.1 is likely unsolicited mail. To reduce the amount of spam sent to
550-5.7.1 Gmail, this message has been blocked.
END QUOTE
I'll see if a direct send gets the same treatment.
===
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D910723-3325-425A-9E72-2F6DE99D1067>