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 4406E2ECE86 for ; Fri, 17 Apr 2026 13:03:10 +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=1776430994; cv=none; b=ReeHRECcynnPLjkA4zKPP98vkw0GRc7lbQyv2RC3c664hESYUBM9w83Kxbupa8ZTgSaM35gmo6BI4I6yHiE0H7QCOIMDSYeyJ27ez0UX/2SuybztBezWvlttwbXKkqKXV4LRFi0Z7tuUn0D4DBVFVIxODevueQC1+aOQQU4oVIA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776430994; c=relaxed/simple; bh=66efPqHB4OTBIAAG4quM/B4hWbB/SqlWIBsO/TlmQWg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=etZ7c3ihufdOTXjoW6AdXinfGx5+m2nAu0zeUs+GK+uKFa9/zcm3ytagXBkDPUOHPlmmwM7HpOfuoxOpAisQwS+SJIN54kKx4+5laZ9I3RhW5ASs0tCqnichpNBghNEtvhWvrwFOjgPmWb8SOt4NPtzweTWW7482ZMPe3EB5wY8= 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=gllMaTR2; 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="gllMaTR2" 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=jFGslLQL4z4PowPtlmAyWHQnyC73HKWsGKqT1Jxz8S4=; b=gllMaTR25EYyatLlF8y0M3xjAF xpLAuDE/TPabF8Z+htIlsJ8V1jsVuL7xJZrNjITB6SvlxlfYokpEsKUEuxgup0ZabgACniihz6hGM 23rAe3oeFAX6MIc9ehLHgZBGqewYviRVNy32C+CS1md0sYg8z8Wp529i03Kdb4W9rSCWozPUiASOn JvMq0Ha6dosHgcx5yjDahZXljsKsJ6wMKR/4Jcb0yuSBW/nCFsTLKEd5Ozq8zVibegoucxBPakr8n Vqbmgobwr9F/3dUvLjW6uvvuYTaV3CGRPhrFXAL/KyiBBOQTI0sO0OhMlTkQntJZBFMTYefStsk42 yhrKHNJQ==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1wDiqe-00000003w2e-221V; Fri, 17 Apr 2026 13:03:04 +0000 Date: Fri, 17 Apr 2026 14:03:04 +0100 From: Matthew Wilcox To: "David Hildenbrand (Arm)" Cc: ZhengYuan Huang , akpm@linux-foundation.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> <66f67e51-819b-4c60-9f61-170db32362a2@kernel.org> 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 01:57:59PM +0200, David Hildenbrand (Arm) wrote: > On 4/17/26 12:53, David Hildenbrand (Arm) wrote: > > On 4/17/26 03:16, ZhengYuan Huang wrote: > >> [BUG] > >> madvise(MADV_HWPOISON) can fault a swap entry back in through > >> get_user_pages_fast() and hit: ... > >> I can reproduce this issue deterministically on v6.18, but I have not > >> been able to reproduce it with the same setup on next-20260415. > > Just speculating, we had > > commit 3b617fd3d317bf9dd7e2c233e56eafef05734c9d > Author: Lorenzo Stoakes > Date: Mon Jan 5 20:11:49 2026 +0000 > > mm/vma: enforce VMA fork limit on unfaulted,faulted mremap merge too > > Go into v6.19. > > Maybe there was a scenario where we could have lost vma->anon_vma during > a merge, resulting in a swapped page in an anon_vma. > > If this cannot be reproduced on 6.19+,there is nothing to worry about. ... except that 6.18 is LTS so we need a fix for that kernel version. And maybe 6.12 as well (a373baed5a9d went into 6.9, so no need to go further back than that)