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 36C9C2C0261 for ; Sat, 18 Apr 2026 09:39:00 +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=1776505141; cv=none; b=AZ84QQJw2RkqjXi0JiIo8tZKPCn3N0JMTADVlawvkB38tcbCaTCIjdUoWTfV3n7PqOZhquUEAZuKY0cOUzsZ+SljGvNyZrcyiGEZoJW6cLqwXRqXjF+3z0bmZV6zVDQgpKCTPZcL/oMZ6LOoBNRH1Pk7a8FuNIQ5dlDWVG9LpiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776505141; c=relaxed/simple; bh=OiHw+xaRzqDQPMVp8PWdrbPrq4CXv8i6VOioXMCbP0U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pWUar53/Md9YHBMHqlOHEdUs0xX9QA0RPiseg0BDYG7d6x8EWD4dADKXDiDEvlR9ppUUR5Ycg/2ehz4fM+QsfBtR36PbM7i9swb3fKoYyQvZoqFJ2kBSp+vNVGnjkrZVkV5nDpqgO/OEOr1gFrVdGSmsOzKL2SzCkckOMtag/eQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pvw9b8ab; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pvw9b8ab" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F08DC19424; Sat, 18 Apr 2026 09:38:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776505140; bh=OiHw+xaRzqDQPMVp8PWdrbPrq4CXv8i6VOioXMCbP0U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Pvw9b8ab5Z+V9ULudbbwhFHG/3PQXakntReoDaqHoiVMow4mW+PxaBLNUBUQQJUMs fpu/1dr2OYEKiV1Cu0BxLxUFvSoJX3FVKLRWDMvi5arSO4zKYdFTURMaTm9AOeXtd0 LVEv1trR7gMyDgutonaPHkST4ufI7DAmiD46jKMSHgxsZ0NKnAwZesjscUMp+Tnfqr reE25bDfM7VrQH03rwRF5//V/EvQTeQjjifj21ajkDfg35J+SAw24LVrv7oH05J544 WkfBq1Jd5kDhlbKygqYwYOba0HEgMPm23NdEAZovwzdEWj0oBtYCvWmKFXXlF2wAz0 rcUcEx8P6w/qw== Date: Sat, 18 Apr 2026 10:38:54 +0100 From: Lorenzo Stoakes To: Matthew Wilcox Cc: ZhengYuan Huang , akpm@linux-foundation.org, david@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com Subject: Re: [PATCH] mm: prepare anon_vma before swapin rmap Message-ID: References: <20260417011606.1089985-1-gality369@gmail.com> 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-Disposition: inline In-Reply-To: On Fri, Apr 17, 2026 at 05:03:19AM +0100, Matthew Wilcox wrote: > On Fri, Apr 17, 2026 at 09:16:06AM +0800, ZhengYuan Huang wrote: > > Commit a373baed5a9d ("mm: delay the check for a NULL anon_vma") moved > > anon_vma preparation out of the generic fault path and into the fault > > handlers that actually need to install anonymous rmap state. > > > > do_swap_page() was left behind. It can still restore anonymous mappings > > via folio_add_new_anon_rmap() or folio_add_anon_rmap_ptes(), but it does > > not call vmf_anon_prepare() first. On a VMA-lock fault this can leave > > vma->anon_vma NULL all the way down to __folio_set_anon(), which BUG_ONs > > on that violated invariant. > > Huh. Can you share your reproducer? I wonder if there's an equivalent > problem with do_numa_fault(). And maybe the right solution might be > to put the call to vmf_anon_prepare() in handle_pte_fault() instead. > > I'm asking because I don't quite understand how we get to this point > without an anon_vma being assigned to this VMA. We should allocate one on > the first fault ... so we cannot have ever faulted, but if we've never > faulted, how does madvise() manage to swap out a page if none has been > allocated? Yeah there really isn't any way this should be possible unless something else is causing a bug here. My recent anon_vma changes are too new for them to be the culprit I think :)) > > (also if you share your reproducer, perhaps someone will add it to the > self-tests and maybe it'll prevent another bug in the future) Yes, if this is a real bug we really need to see how this is happening. Thanks, Lorenzo