From nobody Sat Nov 22 16:37:19 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 4dDHmv5rrDz6HQQR for ; Sat, 22 Nov 2025 16:37:19 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dDHmv5BCrz3QMn; Sat, 22 Nov 2025 16:37:19 +0000 (UTC) (envelope-from mmel@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763829439; 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=Q1NxrJLZ0duk+WdtJp/95zEYQErWHlacrV17lvFMNeU=; b=H8E+0+MJLBqzyduMVjqb9ggeDNkY3B1Oi9cDNt+fwNzqijETvkzkxv7CKbxZTBQUAmzHl/ ZAQy9W/CcCKcxCOvVFW4NqXvdDtY2BioNZLCGBqX1EMp4c2ZYYL5gmY8P3ujVFXaHEeX04 UpEMqfqCDvFVJXJm8f0V5JhzAbeGA9c03Ul3y6AzUzHV5ekGx82BRR0+zIOE1fqKBFHAiC E7GZ6naEytCk0+6NCmlY+hsPHEdOzk6bcFu4B3Q2KvExxTxj/UjvrRkpKgPJY9qwI35VWw 8wieVQU62mFUcjBYu3w3wdPaTC7t+V+ejSYZyb3aK0opS5dhep35TYj0VTHv/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763829439; 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=Q1NxrJLZ0duk+WdtJp/95zEYQErWHlacrV17lvFMNeU=; b=pb1m7tzQ93Co5TtYD1oim5qbkczP8rM19a75mlvrY0teUG3YtWatNT0gr5ni3z2U9noAaM 9XSLZJD5V6B6lunVYBjshOkWhwMbfYGRR1x2x8dr9Y/cIkg28v3VCPSKPEdBEqhcDoyfv1 6Ue+abEwPS2ZXgdRCrDgqzU5QbofU/QQoJ7O3VI4h6Fexf3OQEe2j2VGQFGAOlK8901oHK xmsCs6RhC49LPl/dlBuJdUwMoeEyvy/CtdP+7LYgXfW1gK7ZuBitqWAgGHdAaMDhFs4ijz T44YuhbDwCFD7u4IY56EXTSrafD6Bc/yPD561pnHDwFO2ED3lN/LJn60UiEy/A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763829439; a=rsa-sha256; cv=none; b=oUGQEUSV2XrLqmICwjaqGkn5BM76KVLJc9oponHCyQgF9YBKZUQmfA9coi+OzGoa1tNZpT 8eLN41v20xi6opB954ceRyzPvRQWcQjgwV6uNV1gsLARXtkgzIKlCEIu+k2gRlgrh1BTyr hjm4SDRiOYDt5c80Um5WPbSJFbSvMQ1bzUA4llK7NfH8i0DfkrwH7QaRqg4TX1gj8F1cNQ 1jfhJVxsfn9j+bY2XFY24VbrsAwVgQD8Zb+6275AgaI+Ij6EYyscZkiBNoQPqs/pO8MbgA anZPIUkkUGMH03PQamOKA+cB0cyvqq8gvvjjErd3SpiZTD3gK7nd2IRzoT5i/Q== 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 4dDHmv2Cybzrlj; Sat, 22 Nov 2025 16:37:19 +0000 (UTC) (envelope-from mmel@freebsd.org) Message-ID: Date: Sat, 22 Nov 2025 17:37:19 +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 References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> Content-Language: cs, en-US Cc: FreeBSD Current In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22.11.2025 16:40, Konstantin Belousov wrote: > On Sat, Nov 22, 2025 at 03:31:24PM +0100, Michal Meloun wrote: >> This patch KASSERTs almost immediately when the system enters multi-user >> mode while processing mmap() syscall: >> >> panic: vm_object_coalesce: obj 0xc73ddb28 next_pindex 0x13 next_size 0x5 >> obj_size 0x176 > > Yes, the assert was mis-placed. Please try this variant. > > commit 2b1a1bcd2926bd89b8422c665b0aa411e29c883b > Author: Konstantin Belousov > Date: Sat Nov 22 16:02:50 2025 +0200 > > vm_object_coalesce(): fix logic to detect coalesce possibility, simplify > > 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, that didn't help. I will try the vm_map.c patch again for confirmation.