From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 E42872C86D for ; Fri, 17 Apr 2026 04:03:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776398609; cv=none; b=sO2a5Lxr51Wxioy30gm7ywtPIFBfAYhs6IUQH9/Ti77ayFuFqS65StNh7YnZjO3l2tmhsTp7mMAmszwJtB3ZW5x48KQibEKMPSkS5DAQy1sYy0mjfUI62Pqva9ZnpzdaTBw7vAaHe2M4VkAbOfcu51gZoN/RLYKKdyr2ay/HrRY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776398609; c=relaxed/simple; bh=f+q8vYbLoCrz+FUY0vuekqRMY/BZTvLCxWGHitlXoC0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sqppAeScgB30Z3iiNCPL14E4aZOBWPU8DNoAIiqXkaar5MxorkFIQiIghBD96+hVC6GxKUCsL3BAsaNlwtroq2v5GbxyAnX/nPrWMKWME1rOWAgtKBVwBGzOIcuEiV/piwiBdj1B46OdtWhlAdx9WT6xNOxSWbPqpoWX8lltdME= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=JXNjbuDc; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="JXNjbuDc" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4lWjRfIjCGyLGQglXl0+KvP7dWOHVwzR+Zz4odaMyd4=; b=JXNjbuDcrKUZuZErpqDBQkZSg3 wbt7gfY49yru7XIMpEiwLkKyWVBT82oQgPhJyfdVMJxHfkVnNexZzt0vWZK42BRuqwnJ9Kp+7sfyy Z2RQ1DfpGP3M+qTDykkAem82+5N4Wxw/bpqYZrB2AM8sSrKbKXKWjgbZNYLduJOakSb3vbs/71JmL vdeRe4v2MkY3ZTZPSSudI5szcdzPwZCla3X6uXpYHu9s4Cn0r6BONdRsdrSSXChhmUmnq+/g711dl INfbcBqpMJkm20MfSowsnzDoUj/DoQKVL2PBVGE+Epvz7Ze6C5+Mi+iZQMbVcd831pLo9fadZtpb5 gr0L4Mog==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1wDaQJ-00000002hmx-2VC6; Fri, 17 Apr 2026 04:03:19 +0000 Date: Fri, 17 Apr 2026 05:03:19 +0100 From: Matthew Wilcox To: ZhengYuan Huang Cc: akpm@linux-foundation.org, david@kernel.org, ljs@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: <20260417011606.1089985-1-gality369@gmail.com> 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? (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)