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 DF4FF3CCFB7 for ; Wed, 22 Apr 2026 10:20:23 +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=1776853224; cv=none; b=I+lbIobHdK3bYTgfn2LhN6xl/CdwND8jZF3IVF7RlRUC/lLoVBS6o52zekd2VESs5MIzgvBY0WC+qbqw90HBYmWid5jOFc/LouZYPOr7NoWEwQSbezuzJ4gDq5lKfKVqekh3jntB4UkxEzGkzY4HaSBihe0Aqqa1mt0wORSrJYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776853224; c=relaxed/simple; bh=2rO0A9K+uKblWGZ7ie12xOMAcsB0BFhdWOdf48JACFo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jeOtGFYssv6OgGHLZRAEpQMhzoUrUZLxVrzbmAwhUWMFEoe8Wh5cWufD/oZ0UcEPQ01rTWkvPx/HlV8RsUALduAr8K3Y0B3d1Y0t/8yZTDmP6vHDrzmq44NbdpS/MWggF9cVhCidQDE8n7qeUBt36gkszvL6hT2cYUNVw8U+TMY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NIu6y7lu; 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="NIu6y7lu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3004C19425; Wed, 22 Apr 2026 10:20:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776853223; bh=2rO0A9K+uKblWGZ7ie12xOMAcsB0BFhdWOdf48JACFo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NIu6y7luJXUKZKKm2bVTfB9tV3JIB5a39xhEkpJV/g2d5QZk2E/XzoM/TLCZjLnWa geqWNNsHdag3CipAyqxsRuFa4FnbUBqBd4YKmkVm0NHf87M3CiR1asYkC+YVNnxown cSKK0g+3EGA+dQd2uQ9AL7QbV1AVbzUTjm7gUhfIaRYkGgDXypzeaa81oYr38eKS+7 p9LMm/YMO8NSmCILvhAcJSeICIY1eJ+X07tdmr9+0K2JmbvmAtJr1xdQJ6aE1pjIo8 l5txp9FWdV7CfAVfnCrmQJEDk5RahtAo8v+z8+HhxD7wJMwMHR8scFOdZITin0LWaB SLlMJ2xF8n20w== Date: Wed, 22 Apr 2026 11:20:16 +0100 From: Lorenzo Stoakes To: ZhengYuan Huang Cc: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, willy@infradead.org, 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> <7b983108-4846-46ce-b9f5-2aef319c00dd@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Apr 22, 2026 at 03:59:57PM +0800, ZhengYuan Huang wrote: > On Sun, Apr 19, 2026 at 10:21 PM Lorenzo Stoakes wrote: > > > > On Sun, Apr 19, 2026 at 10:19:59AM +0200, David Hildenbrand (Arm) wrote: > > > On 4/18/26 11:35, Lorenzo Stoakes wrote: > > > > On Fri, Apr 17, 2026 at 01:57:59PM +0200, David Hildenbrand (Arm) wrote: > > > > > 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. > > > > > > > > Unless there's a bug (and correct me if I'm misinterpreting), VMA merge requires > > > > vma->anon_vma to either be equal for merged adjacent VMAs, or one or the other > > > > VMA to have NULL vma->anon_vma, in which case we set vma->anon_vma in the merged > > > > VMA. > > > > > > I think you didn't understand what I was trying to say. > > > > Let me take more of a look then! > > > > > > > > The reporter claimed that it happened on 6.18. Nobody knows on which patch > > > version (stable tree?). > > > > > > I was wondering whether your fix > > > > > > 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 > > > > > > that went into 6.19 might have resolved this problem. > > > > Ahhh, no not that one (it affects merge of VMAs that have a CoW hierarchy which > > we shouldn't allow) but 61f67c230a5e actually could cause this. > > > > Can see from https://kernel.dance/#61f67c230a5e it was backported to 6.18.7 I > > think. > > > > ZhengYuan - can you try seeing if it repro's with/without that? > > > > If you're testing literally at v6.18 in Linus's tree say and NOT on a stable > > tree, then that's your problem - you're essentially testing a known-buggy kernel > > (we always find stuff later and send to stable, just how it is). > > I can reproduce the issue on 6.18.7, but I can no longer reproduce it on 6.18.8. > So it does look like the problem has already been fixed by commit 61f67c230a5e. > > Thanks everyone for the insights and pointers. Pointers always makes me think of https://xkcd.com/138/ ;) Thanks for reporting the issue, I'm glad that the fix has that handled (mea culpa for introducing the bug! :) > > This issue was originally found by our fuzzing tool. Unfortunately, > our reproducer generation is still a bit unreliable, so I cannot > provide a standalone reproducer at the moment. However, given that the > issue appears to be fixed, I suppose that is no longer strictly > necessary. > > Let me know if further testing is needed. No that's fine, you've confirmed the expected revisions and really I think it has to be that fix that got it. > > Thanks, > ZhengYuan Huang Cheers, Lorenzo