From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AACB735F193 for ; Sun, 5 Jul 2026 22:27:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783290430; cv=none; b=Pasrw8oQad8ke3WVGB7eM0dDohq2/hlMNJbYWSsmn8ox4/hjcq0b2YsrhEBB9LJHJsOYKZ+oogM7xLOTkKLlmYLeWvvIcKA17nSBbraucwqhgY8OSO+UsNWZY7QExAdPyyRWTcwZa4IESNAVL0U2V4+4N8kR4yAvuBsW3FmF7y8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783290430; c=relaxed/simple; bh=WyfSfYZ2fCon/Ytt1wJdI9JKK1XbRYiYZ4hD9y+UXes=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=ImnyrR0qC/S1Ajl6XqeVK3kPo5k6v62feEPurjzcYK/oubi66R3UBetkLEcsQX0W6GxqkVDdis8TYvuwRv9jixTB9lnO3FikJgmWSHf2jIDPYlyqWo7a9z6iea46kjCafbM1Lab67p9oAOPsv0EHcgQY1L0GlxRbohEjw2m5sj0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=vWd9PH4+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="vWd9PH4+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CE231F000E9; Sun, 5 Jul 2026 22:27:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1783290429; bh=Jv2xcJUD95C+Cm3j0a8p9yFOX4F6reCnN2sLjCktK30=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=vWd9PH4+zF/ek7rkQK7nPfLAYMQVfP5lqY+NM+kCTLWqo+X38fwCxKAyy0FnFyG1P MiUegVKczEMU5b8yTm6ic0qG+vKHG1auoyMcR+HkEBJOqDBamYBDAP6k7kPNednXR2 obkSLcLVKAuZAsYFODXUXZM6LIA732tk25e5j3Lg= Date: Sun, 5 Jul 2026 15:27:08 -0700 From: Andrew Morton To: Hajime Tazaki Cc: liam@infradead.org, ljs@kernel.org, vbabka@kernel.org, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: nommu: point to the write iterator upon split_vma Message-Id: <20260705152708.582fd8d87561f600da23c0a7@linux-foundation.org> In-Reply-To: <20260702012546.665383-1-thehajime@gmail.com> References: <20260702012546.665383-1-thehajime@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 2 Jul 2026 10:25:46 +0900 Hajime Tazaki wrote: > When users munmap(2) the partial region allocated by mmap, it might > split the original region if necessary and shrink to the right size. > At the begining of vmi_shrink_vma(), it clears the unused part but > generates assetion when the shrink happenes after split_vma(). > > This commit fixes this issue by configuring the right pointer to the > iterator at the end of split_vma(). > > This was detected with a LTP (Linux Test Project) test, which linked > below, on the nommu UML environment (out-of-tree extension to UML). > > Here is a minimal reproducible chunk of code for this issue: > > void *addr; > size_t pagesize = getpagesize(); > > addr = mmap(NULL, pagesize * 4, PROT_READ | PROT_WRITE, > MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > munmap(addr + pagesize * 1, pagesize); > > This is the console output with CONFIG_DEBUG_MAPLE_TREE=y. > > nommu: WARN at __mas_set_range:791 (1) > MAS: tree=0000000091c23b08 enode=0000000065057663 > (ma_active) > Store Type: > node_store > [9/9] index=70af8000 last=ffffffffffffffff > min=0 max=ffffffffffffffff sheaf=0000000000000000, request 0 > depth=0, flags=0 > maple_tree(0000000091c23b08) flags 307, height 1 root 0000000083394c06 > 0-ffffffffffffffff: node 0000000010c90bd6 depth 0 type 1 parent > 0000000050e1ddf8 contents: 0000000000000000 707A > 7FFF 00000000eb0ac2b5 707AFFFF 0000000000000000 7093FFFF > 0000000045ead616 7095FFFF 0000000000000000 7096CFFF 000 > 00000681c7151 7096FFFF 0000000000000000 70AF3FFF 000000006c78b9e9 > 70AF4FFF 000000001914ab0b 70AF7FFF 00000000000 > 00000 FFFFFFFFFFFFFFFF 0000000000000000 0 0000000000000000 0 > 0000000000000000 0 0000000000000000 0 0000000000000 > 000 0 00000000bca8be4f > 0-707a7fff: 0000000000000000 > 707a8000-707affff: 00000000eb0ac2b5 > 707b0000-7093ffff: 0000000000000000 > 70940000-7095ffff: 0000000045ead616 > 70960000-7096cfff: 0000000000000000 > 7096d000-7096ffff: 00000000681c7151 > 70970000-70af3fff: 0000000000000000 > 70af4000-70af4fff: 000000006c78b9e9 > 70af5000-70af7fff: 000000001914ab0b > 70af8000-ffffffffffffffff: 0000000000000000 > nommu: Pass: 796 Run:797 Thanks. Unfortunately we aren't very diligent about the nommu code (are we?). Perhaps appropriately - clearly this code doesn't get used a lot. It appears that AI review has found another issue in there: https://sashiko.dev/#/patchset/20260702012546.665383-1-thehajime@gmail.com > --- a/mm/nommu.c > +++ b/mm/nommu.c > @@ -1367,6 +1367,10 @@ static int split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, > setup_vma_to_mm(vma, mm); > setup_vma_to_mm(new, mm); > vma_iter_store_new(vmi, new); > + > + /* vmi should point lower address */ > + if (new_below) > + vma_next(vmi); > mm->map_count++; > return 0; Lorenzo, others: do you have the time? Thanks.