From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9C4BB1684BE for ; Thu, 15 Jan 2026 19:01:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768503715; cv=none; b=dxr1av5q0DyoDUXj2Q/1Mk/Ycl7/w8DukZ/c4mWeOioFyQ8LIDuVwA0naztSIwuyFcmUg51YMb5yNGwBMqO483f4RuCMerpowRIpXta7fpFcIf0a6f1sjob9pAtu071R2RKiDUD2Bejo1fx9KZ94hnmYvdtgdPwKvbSCz84O5Fo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768503715; c=relaxed/simple; bh=LHcYX+Z+d/gwODkx5g8AACAS429Tx2260kehahsLLk4=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=IYdwceuM7E1IAG0KPZ8/YtSUiToo64LkA6ZpWRxhznmrx2FtNZO38cXYBf4HbyUG+qhoeV1g9RJ85GVLLED/m95h8AKQBjg5+nTY2VTiqXhR32f0laSAu44CQcn7cuuqx+rp2gCpqNLK1WQ27cnNJeU+jfnvS8FLMj6qN/BmL5w= 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=ezGyhA96; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="ezGyhA96" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1927C116D0; Thu, 15 Jan 2026 19:01:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1768503715; bh=LHcYX+Z+d/gwODkx5g8AACAS429Tx2260kehahsLLk4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ezGyhA96PzgQpjxFSnd5n9IRmgI6kK4PszDio9VL5LHGwB3tKwtHaHyBfAKsl4V/F vee3wJ5q8lg6BQeOODY4LiYvzGftz5EL1cVs6rh5IJypQxORLfuPSEJXDcWa5MpM7T PQESeetoWGQZjBQ4hDLXs3nxa3VyaS2ZCiFJ/Fv8= Date: Thu, 15 Jan 2026 11:01:53 -0800 From: Andrew Morton To: "Liam R. Howlett" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Suren Baghdasaryan , Lorenzo Stoakes , Pedro Falcato , David Hildenbrand , Vlastimil Babka , Michal Hocko , Jann Horn , shikemeng@huaweicloud.com, kasong@tencent.com, nphamcs@gmail.com, bhe@redhat.com, baohua@kernel.org, chrisl@kernel.org, Matthew Wilcox Subject: Re: [PATCH v2 00/10] Remove XA_ZERO from error recovery of dup_mmap() Message-Id: <20260115110153.bbbce63a68df01d8cd4e6eaa@linux-foundation.org> In-Reply-To: <20260115182720.1691130-1-Liam.Howlett@oracle.com> References: <20260115182720.1691130-1-Liam.Howlett@oracle.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, 15 Jan 2026 13:27:10 -0500 "Liam R. Howlett" wrote: > It is possible that the dup_mmap() call fails on allocating or setting > up a vma after the maple tree of the oldmm is copied. Today, that > failure point is marked by inserting an XA_ZERO entry over the failure > point so that the exact location does not need to be communicated > through to exit_mmap(). > > However, a race exists in the tear down process because the dup_mmap() > drops the mmap lock before exit_mmap() can remove the partially set up > vma tree. This means that other tasks may get to the mm tree and find > the invalid vma pointer (since it's an XA_ZERO entry), even though the > mm is marked as MMF_OOM_SKIP and MMF_UNSTABLE. > > To remove the race fully, the tree must be cleaned up before dropping > the lock. This is accomplished by extracting the vma cleanup in > exit_mmap() and changing the required functions to pass through the vma > search limit. Any other tree modifications would require extra cycles > which should be spent on freeing memory. > > This does run the risk of increasing the possibility of finding no vmas > (which is already possible!) in code that isn't careful. > > The final four patches are to address the excessive argument lists being > passed between the functions. Using the struct unmap_desc also allows > some special-case code to be removed in favour of the struct setup > differences. Thanks, all. I quietly added this series to mm.git's mm-new branch. All being well I shall move it into mm.git's mm-unstable branch (and hence into linux-next) a few days from now.